TCK - yet another milestone passed
Hi all, What a wonderful and productive week? What a team effort? Over the night, we went under 100 failures. 197 last week, 86 this week We are getting so close to the certification. As said already, the last failures are usually harder to fix and take more time. Help and contributions are still welcome. If you feel you want to be part of the fun Let us know we can help you get started. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
Re: Permanently Fixing examples after library upgrades - help wanted
> On Apr 8, 2021, at 12:12 AM, Zowalla, Richard > wrote: > > (b) I only know the "jira-rest-java-client-core" provided by Atlassian > (see > https://mvnrepository.com/artifact/com.atlassian.jira/jira-rest-java-client-core/5.2.2 > ) - might be worth a try? Sadly, it will only work with the self-hosted > Jira Server instance. I do not know, if ASF is using the cloud-hosted > approach offered by Atlassian... Apache does self-host, so we're good on that front assuming there aren't specific options that need to be enabled. I don't want to take too much of my time away from TCK work, but I'll see if I can create a small CLI for the jira-rest-java-client-core. We could use it to file JIRAs for the remaining TCK failures so we could divide and conquer on that too. If we could get even one or two more people helping there it'd make a huge difference. When we did the long march to Java EE 6 Web Profile compliance, we had about 4 or 5 of us working on it after hours in bursts, averaging what felt like about 1.5 FTEs at any given time. Every little bit helps. Even getting 2 or 3 more people doing one test each would have a very big impact. I think with the current status, no one knows who is working on what test so people are more inclined to stay out of the way. Some JIRAs can definitely fix/improve that. We actually couldn't file JIRAs for the remaining failing tests when we did Java EE 6 as the TCK at that time was commercially licensed and under NDA. We don't have that issue any more :) -David smime.p7s Description: S/MIME cryptographic signature
Re: Java 16 via 8.0.7-SNAPSHOT - JVM Crash - Any Thoughts?
Thanks, Jon! Am Donnerstag, den 08.04.2021, 13:19 +0100 schrieb Jonathan Gallimore: > I'll take a look anyway - I'm wondering if we can do anything to > avoid the > need for --illegal-access=permit. > > Jon > > On Thu, Apr 8, 2021 at 1:09 PM Zowalla, Richard < > richard.zowa...@hs-heilbronn.de> wrote: > > > A little update: It seems the problematic thing is "JEP 396: > > Strongly > > Encapsulate JDK Internals by Default", which was introduced with > > Java > > 16. Adding "--illegal-access=permit" (default of Java 9) to the > > commandline arguments restored the behaviour of pre-Java 16. > > > > Creating the minimal example as well as the related exception > > instead > > of a JVM crash helped a lot. > > > > The JVM crash in the project is gone and everything seems to work > > like > > a charm (deployment, ...). I will run some additional tests with > > the > > deployed application but it is looking good at the moment, so for > > now: > > > > Java 16 seem to work fine with the current 8.0.7-SNAPSHOT + OpenJPA > > 3.1.3-SNAPSHOT). > > > > Gruss > > Richard > > > > Am Donnerstag, den 08.04.2021, 11:42 + schrieb Zowalla, > > Richard: > > > Sadly, I cannot reproduce the JVM crash in my minimal example. > > > > > > However, it reveals some other (probably access-related) issues > > > in > > > LocalBeanProxyFactory.createProxy(...) which might have lead to > > > the > > > crash in the actual project. > > > > > > It can be found here: https://github.com/rzo1/jdk16-testing > > > > > > Gruss > > > Richard > > > > > > > > > Am Donnerstag, den 08.04.2021, 11:55 +0100 schrieb Jonathan > > > Gallimore: > > > > A minimal example would be a big help, thank you! > > > > > > > > Jon > > > > > > > > On Thu, Apr 8, 2021 at 11:00 AM Zowalla, Richard < > > > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > > > > > Hi Jon, > > > > > > > > > > thanks for your response. > > > > > > > > > > I am using the latest OpenJDK 16 build from AdoptOpenJDK ( > > > > > https://adoptopenjdk.net/?variant=openjdk16&jvmVariant=hotspot) > > > > > on > > > > > a > > > > > Ubuntu 20.04 LTS system. > > > > > > > > > > If it helps: I could try to create a minimal example to > > > > > reproduce > > > > > the > > > > > crash and push it to Github. > > > > > > > > > > Gruss > > > > > Richard > > > > > > > > > > Am Donnerstag, den 08.04.2021, 10:39 +0100 schrieb Jonathan > > > > > Gallimore: > > > > > > I did some of the original work on LocalBeanProxyFactory > > > > > > way > > > > > > back. > > > > > > I'm > > > > > > happy to take a look. Are you building your own JDK from > > > > > > source, > > > > > > or > > > > > > downloading a specific binary (if so, which one)? > > > > > > > > > > > > Jon > > > > > > > > > > > > On Thu, Apr 8, 2021 at 8:07 AM Zowalla, Richard < > > > > > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I am doing some bleeding edge testing related to JDK/JRE > > > > > > > 16 > > > > > > > with > > > > > > > the > > > > > > > latest TomEE 8.0.7-SNAPSHOT as we have included some 3rd > > > > > > > party > > > > > > > patches, > > > > > > > which should support JDK/JRE 16. One remaining thing is > > > > > > > OpenJPA, > > > > > > > which > > > > > > > will support J16 with 3.1.3-SNAPSHOT (so I have patched > > > > > > > it in > > > > > > > my > > > > > > > test). > > > > > > > > > > > > > > I get this weird JVM crash [1] probably related to > > > > > > > LocalBeanProxyFactory when deploying a JSF/JAX-RS WAR > > > > > > > archive > > > > > > > via > > > > > > > the > > > > > > > TomEE Maven Plugin. Maybe someone has some thoughts on it > > > > > > > (or > > > > > > > a > > > > > > > hint)? > > > > > > > > > > > > > > Gruss > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > https://gist.github.com/rzo1/cf70056a0a27d4cb5a714d6211dc7563 > > > > > > > > > > > > > > > > > > > -- > > > > > Richard Zowalla, M.Sc. > > > > > Research Associate, PhD Student | Medical Informatics > > > > > > > > > > Hochschule Heilbronn – University of Applied Sciences > > > > > Max-Planck-Str. 39 > > > > > D-74081 Heilbronn > > > > > phone: +49 7131 504 6791 > > > > > mail: richard.zowa...@hs-heilbronn.de > > > > > web: https://www.mi.hs-heilbronn.de/ > > > > > > > -- > > Richard Zowalla, M.Sc. > > Research Associate, PhD Student | Medical Informatics > > > > Hochschule Heilbronn – University of Applied Sciences > > Max-Planck-Str. 39 > > D-74081 Heilbronn > > phone: +49 7131 504 6791 > > mail: richard.zowa...@hs-heilbronn.de > > web: https://www.mi.hs-heilbronn.de/ > > -- Richard Zowalla, M.Sc. Research Associate, PhD Student | Medical Informatics Hochschule Heilbronn – University of Applied Sciences Max-Planck-Str. 39 D-74081 Heilbronn phone: +49 7131 504 6791 mail: richard.zowa...@hs-heilbronn.de web: https://www.mi.hs-heilbronn.de/ smime.p7s Description: S/MIME cryptographic signature
Re: Java 16 via 8.0.7-SNAPSHOT - JVM Crash - Any Thoughts?
I'll take a look anyway - I'm wondering if we can do anything to avoid the need for --illegal-access=permit. Jon On Thu, Apr 8, 2021 at 1:09 PM Zowalla, Richard < richard.zowa...@hs-heilbronn.de> wrote: > A little update: It seems the problematic thing is "JEP 396: Strongly > Encapsulate JDK Internals by Default", which was introduced with Java > 16. Adding "--illegal-access=permit" (default of Java 9) to the > commandline arguments restored the behaviour of pre-Java 16. > > Creating the minimal example as well as the related exception instead > of a JVM crash helped a lot. > > The JVM crash in the project is gone and everything seems to work like > a charm (deployment, ...). I will run some additional tests with the > deployed application but it is looking good at the moment, so for now: > > Java 16 seem to work fine with the current 8.0.7-SNAPSHOT + OpenJPA > 3.1.3-SNAPSHOT). > > Gruss > Richard > > Am Donnerstag, den 08.04.2021, 11:42 + schrieb Zowalla, Richard: > > Sadly, I cannot reproduce the JVM crash in my minimal example. > > > > However, it reveals some other (probably access-related) issues in > > LocalBeanProxyFactory.createProxy(...) which might have lead to the > > crash in the actual project. > > > > It can be found here: https://github.com/rzo1/jdk16-testing > > > > Gruss > > Richard > > > > > > Am Donnerstag, den 08.04.2021, 11:55 +0100 schrieb Jonathan > > Gallimore: > > > A minimal example would be a big help, thank you! > > > > > > Jon > > > > > > On Thu, Apr 8, 2021 at 11:00 AM Zowalla, Richard < > > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > > > Hi Jon, > > > > > > > > thanks for your response. > > > > > > > > I am using the latest OpenJDK 16 build from AdoptOpenJDK ( > > > > https://adoptopenjdk.net/?variant=openjdk16&jvmVariant=hotspot) > > > > on > > > > a > > > > Ubuntu 20.04 LTS system. > > > > > > > > If it helps: I could try to create a minimal example to reproduce > > > > the > > > > crash and push it to Github. > > > > > > > > Gruss > > > > Richard > > > > > > > > Am Donnerstag, den 08.04.2021, 10:39 +0100 schrieb Jonathan > > > > Gallimore: > > > > > I did some of the original work on LocalBeanProxyFactory way > > > > > back. > > > > > I'm > > > > > happy to take a look. Are you building your own JDK from > > > > > source, > > > > > or > > > > > downloading a specific binary (if so, which one)? > > > > > > > > > > Jon > > > > > > > > > > On Thu, Apr 8, 2021 at 8:07 AM Zowalla, Richard < > > > > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I am doing some bleeding edge testing related to JDK/JRE 16 > > > > > > with > > > > > > the > > > > > > latest TomEE 8.0.7-SNAPSHOT as we have included some 3rd > > > > > > party > > > > > > patches, > > > > > > which should support JDK/JRE 16. One remaining thing is > > > > > > OpenJPA, > > > > > > which > > > > > > will support J16 with 3.1.3-SNAPSHOT (so I have patched it in > > > > > > my > > > > > > test). > > > > > > > > > > > > I get this weird JVM crash [1] probably related to > > > > > > LocalBeanProxyFactory when deploying a JSF/JAX-RS WAR archive > > > > > > via > > > > > > the > > > > > > TomEE Maven Plugin. Maybe someone has some thoughts on it (or > > > > > > a > > > > > > hint)? > > > > > > > > > > > > Gruss > > > > > > Richard > > > > > > > > > > > > > > > > > > [1] > > > > > > https://gist.github.com/rzo1/cf70056a0a27d4cb5a714d6211dc7563 > > > > > > > > > > > > > > > > -- > > > > Richard Zowalla, M.Sc. > > > > Research Associate, PhD Student | Medical Informatics > > > > > > > > Hochschule Heilbronn – University of Applied Sciences > > > > Max-Planck-Str. 39 > > > > D-74081 Heilbronn > > > > phone: +49 7131 504 6791 > > > > mail: richard.zowa...@hs-heilbronn.de > > > > web: https://www.mi.hs-heilbronn.de/ > > > > > -- > Richard Zowalla, M.Sc. > Research Associate, PhD Student | Medical Informatics > > Hochschule Heilbronn – University of Applied Sciences > Max-Planck-Str. 39 > D-74081 Heilbronn > phone: +49 7131 504 6791 > mail: richard.zowa...@hs-heilbronn.de > web: https://www.mi.hs-heilbronn.de/ >
Re: Java 16 via 8.0.7-SNAPSHOT - JVM Crash - Any Thoughts?
A little update: It seems the problematic thing is "JEP 396: Strongly Encapsulate JDK Internals by Default", which was introduced with Java 16. Adding "--illegal-access=permit" (default of Java 9) to the commandline arguments restored the behaviour of pre-Java 16. Creating the minimal example as well as the related exception instead of a JVM crash helped a lot. The JVM crash in the project is gone and everything seems to work like a charm (deployment, ...). I will run some additional tests with the deployed application but it is looking good at the moment, so for now: Java 16 seem to work fine with the current 8.0.7-SNAPSHOT + OpenJPA 3.1.3-SNAPSHOT). Gruss Richard Am Donnerstag, den 08.04.2021, 11:42 + schrieb Zowalla, Richard: > Sadly, I cannot reproduce the JVM crash in my minimal example. > > However, it reveals some other (probably access-related) issues in > LocalBeanProxyFactory.createProxy(...) which might have lead to the > crash in the actual project. > > It can be found here: https://github.com/rzo1/jdk16-testing > > Gruss > Richard > > > Am Donnerstag, den 08.04.2021, 11:55 +0100 schrieb Jonathan > Gallimore: > > A minimal example would be a big help, thank you! > > > > Jon > > > > On Thu, Apr 8, 2021 at 11:00 AM Zowalla, Richard < > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > Hi Jon, > > > > > > thanks for your response. > > > > > > I am using the latest OpenJDK 16 build from AdoptOpenJDK ( > > > https://adoptopenjdk.net/?variant=openjdk16&jvmVariant=hotspot) > > > on > > > a > > > Ubuntu 20.04 LTS system. > > > > > > If it helps: I could try to create a minimal example to reproduce > > > the > > > crash and push it to Github. > > > > > > Gruss > > > Richard > > > > > > Am Donnerstag, den 08.04.2021, 10:39 +0100 schrieb Jonathan > > > Gallimore: > > > > I did some of the original work on LocalBeanProxyFactory way > > > > back. > > > > I'm > > > > happy to take a look. Are you building your own JDK from > > > > source, > > > > or > > > > downloading a specific binary (if so, which one)? > > > > > > > > Jon > > > > > > > > On Thu, Apr 8, 2021 at 8:07 AM Zowalla, Richard < > > > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > > > > > Hi, > > > > > > > > > > I am doing some bleeding edge testing related to JDK/JRE 16 > > > > > with > > > > > the > > > > > latest TomEE 8.0.7-SNAPSHOT as we have included some 3rd > > > > > party > > > > > patches, > > > > > which should support JDK/JRE 16. One remaining thing is > > > > > OpenJPA, > > > > > which > > > > > will support J16 with 3.1.3-SNAPSHOT (so I have patched it in > > > > > my > > > > > test). > > > > > > > > > > I get this weird JVM crash [1] probably related to > > > > > LocalBeanProxyFactory when deploying a JSF/JAX-RS WAR archive > > > > > via > > > > > the > > > > > TomEE Maven Plugin. Maybe someone has some thoughts on it (or > > > > > a > > > > > hint)? > > > > > > > > > > Gruss > > > > > Richard > > > > > > > > > > > > > > > [1] > > > > > https://gist.github.com/rzo1/cf70056a0a27d4cb5a714d6211dc7563 > > > > > > > > > > > > > -- > > > Richard Zowalla, M.Sc. > > > Research Associate, PhD Student | Medical Informatics > > > > > > Hochschule Heilbronn – University of Applied Sciences > > > Max-Planck-Str. 39 > > > D-74081 Heilbronn > > > phone: +49 7131 504 6791 > > > mail: richard.zowa...@hs-heilbronn.de > > > web: https://www.mi.hs-heilbronn.de/ > > > -- Richard Zowalla, M.Sc. Research Associate, PhD Student | Medical Informatics Hochschule Heilbronn – University of Applied Sciences Max-Planck-Str. 39 D-74081 Heilbronn phone: +49 7131 504 6791 mail: richard.zowa...@hs-heilbronn.de web: https://www.mi.hs-heilbronn.de/ smime.p7s Description: S/MIME cryptographic signature
Re: Java 16 via 8.0.7-SNAPSHOT - JVM Crash - Any Thoughts?
Sadly, I cannot reproduce the JVM crash in my minimal example. However, it reveals some other (probably access-related) issues in LocalBeanProxyFactory.createProxy(...) which might have lead to the crash in the actual project. It can be found here: https://github.com/rzo1/jdk16-testing Gruss Richard Am Donnerstag, den 08.04.2021, 11:55 +0100 schrieb Jonathan Gallimore: > A minimal example would be a big help, thank you! > > Jon > > On Thu, Apr 8, 2021 at 11:00 AM Zowalla, Richard < > richard.zowa...@hs-heilbronn.de> wrote: > > > Hi Jon, > > > > thanks for your response. > > > > I am using the latest OpenJDK 16 build from AdoptOpenJDK ( > > https://adoptopenjdk.net/?variant=openjdk16&jvmVariant=hotspot) on > > a > > Ubuntu 20.04 LTS system. > > > > If it helps: I could try to create a minimal example to reproduce > > the > > crash and push it to Github. > > > > Gruss > > Richard > > > > Am Donnerstag, den 08.04.2021, 10:39 +0100 schrieb Jonathan > > Gallimore: > > > I did some of the original work on LocalBeanProxyFactory way > > > back. > > > I'm > > > happy to take a look. Are you building your own JDK from source, > > > or > > > downloading a specific binary (if so, which one)? > > > > > > Jon > > > > > > On Thu, Apr 8, 2021 at 8:07 AM Zowalla, Richard < > > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > > > Hi, > > > > > > > > I am doing some bleeding edge testing related to JDK/JRE 16 > > > > with > > > > the > > > > latest TomEE 8.0.7-SNAPSHOT as we have included some 3rd party > > > > patches, > > > > which should support JDK/JRE 16. One remaining thing is > > > > OpenJPA, > > > > which > > > > will support J16 with 3.1.3-SNAPSHOT (so I have patched it in > > > > my > > > > test). > > > > > > > > I get this weird JVM crash [1] probably related to > > > > LocalBeanProxyFactory when deploying a JSF/JAX-RS WAR archive > > > > via > > > > the > > > > TomEE Maven Plugin. Maybe someone has some thoughts on it (or a > > > > hint)? > > > > > > > > Gruss > > > > Richard > > > > > > > > > > > > [1] > > > > https://gist.github.com/rzo1/cf70056a0a27d4cb5a714d6211dc7563 > > > > > > > > > > -- > > Richard Zowalla, M.Sc. > > Research Associate, PhD Student | Medical Informatics > > > > Hochschule Heilbronn – University of Applied Sciences > > Max-Planck-Str. 39 > > D-74081 Heilbronn > > phone: +49 7131 504 6791 > > mail: richard.zowa...@hs-heilbronn.de > > web: https://www.mi.hs-heilbronn.de/ > > -- Richard Zowalla, M.Sc. Research Associate, PhD Student | Medical Informatics Hochschule Heilbronn – University of Applied Sciences Max-Planck-Str. 39 D-74081 Heilbronn phone: +49 7131 504 6791 mail: richard.zowa...@hs-heilbronn.de web: https://www.mi.hs-heilbronn.de/ smime.p7s Description: S/MIME cryptographic signature
Re: Java 16 via 8.0.7-SNAPSHOT - JVM Crash - Any Thoughts?
A minimal example would be a big help, thank you! Jon On Thu, Apr 8, 2021 at 11:00 AM Zowalla, Richard < richard.zowa...@hs-heilbronn.de> wrote: > Hi Jon, > > thanks for your response. > > I am using the latest OpenJDK 16 build from AdoptOpenJDK ( > https://adoptopenjdk.net/?variant=openjdk16&jvmVariant=hotspot) on a > Ubuntu 20.04 LTS system. > > If it helps: I could try to create a minimal example to reproduce the > crash and push it to Github. > > Gruss > Richard > > Am Donnerstag, den 08.04.2021, 10:39 +0100 schrieb Jonathan Gallimore: > > I did some of the original work on LocalBeanProxyFactory way back. > > I'm > > happy to take a look. Are you building your own JDK from source, or > > downloading a specific binary (if so, which one)? > > > > Jon > > > > On Thu, Apr 8, 2021 at 8:07 AM Zowalla, Richard < > > richard.zowa...@hs-heilbronn.de> wrote: > > > > > Hi, > > > > > > I am doing some bleeding edge testing related to JDK/JRE 16 with > > > the > > > latest TomEE 8.0.7-SNAPSHOT as we have included some 3rd party > > > patches, > > > which should support JDK/JRE 16. One remaining thing is OpenJPA, > > > which > > > will support J16 with 3.1.3-SNAPSHOT (so I have patched it in my > > > test). > > > > > > I get this weird JVM crash [1] probably related to > > > LocalBeanProxyFactory when deploying a JSF/JAX-RS WAR archive via > > > the > > > TomEE Maven Plugin. Maybe someone has some thoughts on it (or a > > > hint)? > > > > > > Gruss > > > Richard > > > > > > > > > [1] https://gist.github.com/rzo1/cf70056a0a27d4cb5a714d6211dc7563 > > > > > > > -- > Richard Zowalla, M.Sc. > Research Associate, PhD Student | Medical Informatics > > Hochschule Heilbronn – University of Applied Sciences > Max-Planck-Str. 39 > D-74081 Heilbronn > phone: +49 7131 504 6791 > mail: richard.zowa...@hs-heilbronn.de > web: https://www.mi.hs-heilbronn.de/ >
Re: Java 16 via 8.0.7-SNAPSHOT - JVM Crash - Any Thoughts?
Hi Jon, thanks for your response. I am using the latest OpenJDK 16 build from AdoptOpenJDK ( https://adoptopenjdk.net/?variant=openjdk16&jvmVariant=hotspot) on a Ubuntu 20.04 LTS system. If it helps: I could try to create a minimal example to reproduce the crash and push it to Github. Gruss Richard Am Donnerstag, den 08.04.2021, 10:39 +0100 schrieb Jonathan Gallimore: > I did some of the original work on LocalBeanProxyFactory way back. > I'm > happy to take a look. Are you building your own JDK from source, or > downloading a specific binary (if so, which one)? > > Jon > > On Thu, Apr 8, 2021 at 8:07 AM Zowalla, Richard < > richard.zowa...@hs-heilbronn.de> wrote: > > > Hi, > > > > I am doing some bleeding edge testing related to JDK/JRE 16 with > > the > > latest TomEE 8.0.7-SNAPSHOT as we have included some 3rd party > > patches, > > which should support JDK/JRE 16. One remaining thing is OpenJPA, > > which > > will support J16 with 3.1.3-SNAPSHOT (so I have patched it in my > > test). > > > > I get this weird JVM crash [1] probably related to > > LocalBeanProxyFactory when deploying a JSF/JAX-RS WAR archive via > > the > > TomEE Maven Plugin. Maybe someone has some thoughts on it (or a > > hint)? > > > > Gruss > > Richard > > > > > > [1] https://gist.github.com/rzo1/cf70056a0a27d4cb5a714d6211dc7563 > > > > -- Richard Zowalla, M.Sc. Research Associate, PhD Student | Medical Informatics Hochschule Heilbronn – University of Applied Sciences Max-Planck-Str. 39 D-74081 Heilbronn phone: +49 7131 504 6791 mail: richard.zowa...@hs-heilbronn.de web: https://www.mi.hs-heilbronn.de/ smime.p7s Description: S/MIME cryptographic signature
Re: Java 16 via 8.0.7-SNAPSHOT - JVM Crash - Any Thoughts?
I did some of the original work on LocalBeanProxyFactory way back. I'm happy to take a look. Are you building your own JDK from source, or downloading a specific binary (if so, which one)? Jon On Thu, Apr 8, 2021 at 8:07 AM Zowalla, Richard < richard.zowa...@hs-heilbronn.de> wrote: > Hi, > > I am doing some bleeding edge testing related to JDK/JRE 16 with the > latest TomEE 8.0.7-SNAPSHOT as we have included some 3rd party patches, > which should support JDK/JRE 16. One remaining thing is OpenJPA, which > will support J16 with 3.1.3-SNAPSHOT (so I have patched it in my test). > > I get this weird JVM crash [1] probably related to > LocalBeanProxyFactory when deploying a JSF/JAX-RS WAR archive via the > TomEE Maven Plugin. Maybe someone has some thoughts on it (or a hint)? > > Gruss > Richard > > > [1] https://gist.github.com/rzo1/cf70056a0a27d4cb5a714d6211dc7563 > >
Re: [VOTE] Apache TomEE on Jakarta EE Compatible Products page
I'd prefer option A. Jon On Sun, Mar 28, 2021 at 12:05 AM David Blevins wrote: > Please see Rob Tompkins' email "[jarkarta-ee] Is there apatite to ever use > Jakarta EE logos on the TomEE site" > > This vote is strictly limited to 1) getting Jakarta EE Platform and > Jakarta EE Web Profile implementations at the ASF listed on the jakarta.ee > compatible products page[1] and 2) use of the "Jakarta EE Compatible"[2] > logo on apache.org websites. > > The rules for either of these require you to be a member of the Jakarta EE > Working Group. > > As I've been on the Working Group from the start and knew this would be > affecting us as Apache is is not a member of the Working Group, I've > ensured we have two options. The vote is to gather feedback on which of > the two options you prefer. > > - Option A: Apache joins the Jakarta EE Working Group and gains the > ability to get Apache TomEE and any other ASF Jakarta EE Platform and > Jakarta EE Web Profile implementations listed on the compatible products > page[1]. As a Member, Apache TomEE and any other ASF Jakarta EE Platform > and Jakarta EE Web Profile implementations can use the "Jakarta EE > Compatible"[2] logo on tomee.apache.org and other *.apache.org sites. In > this path the TCK results summary of tests passed must be hosted on > tomee.apache.org for each certified server version, tck version, jdk and > os combination. The entry for Apache TomEE on the jakarta.ee website > will contain one link to tomee.apache.org for the TCK results summary and > one link to download Apache TomEE at tomee.apache.org. > > - Option B: Apache does not join, however, Strategic Members of the > Jakarta EE Working Group could get Apache TomEE listed on the compatible > products page[1] as an open source implementation they support. As Apache > is not itself a member, we would not be able to use the "Jakarta EE > Compatible"[2] logo on tomee.apache.org. We could use the general > Jakarta EE logo, however. In this path the project does not need to host > TCK result summaries on tomee.apache.org. The entry for Apache TomEE on > the jakarta.ee website will contain one link to said Strategic Member's > website for the TCK results summary and one link to download Apache TomEE > at tomee.apache.org. > > I'm confident we can make either work. > > This vote will close on April 14th so Rob can make his recommendation to > the Board in time for the April 21st Board Meeting. Additionally, the > Jakarta EE 9.1 release is scheduled to go up for vote end of April and > there is some chance we could be compatible by then. > > Note: Even if we vote A, that does not guarantee Apache will join the > Working Group. It would just be an indication that's what we desire. The > desires of all projects and the foundation in general will be considered > and it's ultimately Rob and the Board who make this decision. > > > -David > > > [1] https://jakarta.ee/compatibility/ > [2] https://jakarta.ee/images/jakarta/jakarta-ee-compatible-logo-color.svg
Jenkins PR builder issues
Hi, it seems, that we have lost the Jenkins PR Builder support for PRs by people, who are not in the committer group? - [1],[2],[3] are PRs for which the PR Builder via Jenkins did _not_ run. - [4] was a test PR by myself for which the PR Builder did actually run. Did something change on the Jenkins side, does anybody have an idea or do we need to ask INFRA for some insights? Gruss Richard [1] https://github.com/apache/tomee/pull/781 [2] https://github.com/apache/tomee/pull/779 [3] https://github.com/apache/tomee/pull/777 [4] https://github.com/apache/tomee/pull/778 smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Apache TomEE on Jakarta EE Compatible Products page
+1 for A (same reasons as already mentioned) Gruss Richard Am Mittwoch, den 07.04.2021, 20:29 -0300 schrieb Daniel Dias Dos Santos: > Hello everyone, > > I also vote +1 for option A, I believe it will be a great opportunity > to > have TomEE as a compatible product. > > > Em ter., 6 de abr. de 2021 às 18:42, Cesar Hernandez < > cesargu...@gmail.com> > escreveu: > > > +1 for Option A, since this enables smooth understanding and > > navigation for > > users and developers over ASF projects and their compatibility over > > JakartaEE. > > Having this bridge between the ASF project and Jakarta EE would be > > a good > > synergy in the ecosystem. > > > > El dom, 28 mar 2021 a las 2:27, Alex The Rocker (< > > alex.m3...@gmail.com>) > > escribió: > > > > > +1 for Option A : it think it would be a nice way to promote > > > TomEE to > > > a large audience, while not involving too much overhead since, as > > > I > > > understand, TomEE developers are already using TCK tests for > > > validation purposes. > > > > > > Le dim. 28 mars 2021 à 01:05, David Blevins < > > > david.blev...@gmail.com> a > > > écrit : > > > > Please see Rob Tompkins' email "[jarkarta-ee] Is there apatite > > > > to ever > > > use Jakarta EE logos on the TomEE site" > > > > This vote is strictly limited to 1) getting Jakarta EE Platform > > > > and > > > Jakarta EE Web Profile implementations at the ASF listed on the > > jakarta.ee > > > compatible products page[1] and 2) use of the "Jakarta EE > > > Compatible"[2] > > > logo on apache.org websites. > > > > The rules for either of these require you to be a member of the > > > > Jakarta > > > EE Working Group. > > > > As I've been on the Working Group from the start and knew this > > > > would be > > > affecting us as Apache is is not a member of the Working Group, > > > I've > > > ensured we have two options. The vote is to gather feedback on > > > which of > > > the two options you prefer. > > > > - Option A: Apache joins the Jakarta EE Working Group and > > > > gains the > > > ability to get Apache TomEE and any other ASF Jakarta EE Platform > > > and > > > Jakarta EE Web Profile implementations listed on the compatible > > > products > > > page[1]. As a Member, Apache TomEE and any other ASF Jakarta EE > > > Platform > > > and Jakarta EE Web Profile implementations can use the "Jakarta > > > EE > > > Compatible"[2] logo on tomee.apache.org and other *.apache.org > > > sites. > > In > > > this path the TCK results summary of tests passed must be hosted > > > on > > > tomee.apache.org for each certified server version, tck version, > > > jdk and > > > os combination. The entry for Apache TomEE on the jakarta.ee > > > website > > > will contain one link to tomee.apache.org for the TCK results > > > summary > > and > > > one link to download Apache TomEE at tomee.apache.org. > > > > - Option B: Apache does not join, however, Strategic Members > > > > of the > > > Jakarta EE Working Group could get Apache TomEE listed on the > > > compatible > > > products page[1] as an open source implementation they > > > support. As > > Apache > > > is not itself a member, we would not be able to use the "Jakarta > > > EE > > > Compatible"[2] logo on tomee.apache.org. We could use the > > > general > > > Jakarta EE logo, however. In this path the project does not need > > > to host > > > TCK result summaries on tomee.apache.org. The entry for Apache > > > TomEE on > > > the jakarta.ee website will contain one link to said Strategic > > > Member's > > > website for the TCK results summary and one link to download > > > Apache TomEE > > > at tomee.apache.org. > > > > I'm confident we can make either work. > > > > > > > > This vote will close on April 14th so Rob can make his > > > > recommendation > > to > > > the Board in time for the April 21st Board > > > Meeting. Additionally, the > > > Jakarta EE 9.1 release is scheduled to go up for vote end of > > > April and > > > there is some chance we could be compatible by then. > > > > Note: Even if we vote A, that does not guarantee Apache will > > > > join the > > > Working Group. It would just be an indication that's what we > > > desire. > > The > > > desires of all projects and the foundation in general will be > > > considered > > > and it's ultimately Rob and the Board who make this decision. > > > > > > > > -David > > > > > > > > > > > > [1] https://jakarta.ee/compatibility/ > > > > [2] > > > https://jakarta.ee/images/jakarta/jakarta-ee-compatible-logo-color.svg > > > > > > > -- > > Atentamente: > > César Hernández. > > smime.p7s Description: S/MIME cryptographic signature
Re: TCK debugging tips
Thanks for the detailed explanation! It is indeed very helpful. Might be worth adding this introduction to a README.adoc or a separate HOW-TO-DEBUG.adoc to the "tomee-tck" repository (and link it from the README.adoc) ? Gruss Richard Am Mittwoch, den 07.04.2021, 14:49 -0700 schrieb David Blevins: > Sharing a few tips for happy TCK work. > > ## Opening the TCK in your IDE > > The primary thing you need to debug through TCK tests is the source > setup. Here's a pom.xml I use that you can add to the root directory > of an unzipped Jakarta EE TCK. This is just enough pom.xml to get > the TCK imported as a project in Intellij and sources appear without > compile errors. It does not actually build the TCK. > > - https://gist.github.com/dblevins/43eda499b820a2539a3d88c0e61d65a2 > > > ## Getting a fresh TCK install after modifications > > A critical thing to be aware of is that 1) running the TCK will in > fact modify your install in a handful of ways and 2) some of these > process happen exactly once and will not repeat unless you unpack a > completely fresh TCK install. > > I got tired of repeatedly deleting and unpacking fresh TCK installs > and also wanted a way to see exactly what had been changed after > running tests, so I created a git project from a completely fresh TCK > install. Here it is for those who want to use it: > > - https://github.com/dblevins/jakartaeetck-8.0.2 > > The only changes post-unzip are to add Ant, and my pom.xml and a > .gitignore. With that I can do a `git clean -fd` at any time to > restore my TCK install to a fresh state. I can also do a `git > status` and `git diff` to see exactly what has been modified. > > > ## Setup TomEE, TomEE TCK and TCK in Intellij as one project > > In most debugging scenarios you will need to step into both the test > sources and the server sources. You can't do that easily if they are > setup in separate IDE windows. They really need to be in the same > project. Here's how you can easily do that in Intellij. > > > 1. Open your project settings, select `modules` and click the + > button in the upper right. https://pasteboard.co/JWgsOiJ.png > 2. Select `Import Module` https://pasteboard.co/JWgtGXt.png > 3. Navigate to the `pom.xml` file at the root of your clone of > https://github.com/apache/tomee-tck and select `Open`. > https://pasteboard.co/JWguhKA.png > 4. Repeat steps 1-3, but this time Navigate to the `pom.xml` of > your Jakarta EE 8.0.2 TCK and select `Open`. > https://pasteboard.co/JWgw6Ze.png > > When this is done you should now see all three projects side-by-side > in Intellij. https://pasteboard.co/JWgxmQl.png > > > ## Opening a debug port 5005 to the TomEE server > > Now that the IDE is all setup, you can run a test with debug enabled > and connect using Remote debugging in Intellij. For this to work, > you need to tell the tomee-tck `runtests` script to start the server > with the debug port 5005 enabled via the `-ds` flag as follows: > > ./runtests -ds -c -w tomee-plume > com/sun/ts/tests/jaxrs/spec/provider/visibility > > > ## Running just one failing test in a group > > There will be situations where there is just one test failing in a > group and you don't want to run the whole group, just the one failing > test. The TCK output will print the test names like follows: > > 1/-0/?0 - > com/sun/ts/tests/jaxrs/spec/provider/exceptionmapper/JAXRSClient#java > #clientErrorExceptionTest_from_standalone - PASSED > 2/-0/?0 - > com/sun/ts/tests/jaxrs/spec/provider/exceptionmapper/JAXRSClient#java > #exceptionTest_from_standalone - PASSED > 3/-0/?0 - > com/sun/ts/tests/jaxrs/spec/provider/exceptionmapper/JAXRSClient#java > #filterChainTest_from_standalone - PASSED > 3/-1/?0 - > com/sun/ts/tests/jaxrs/spec/provider/exceptionmapper/JAXRSClient#java > #mappedExceptionTest_from_standalone - FAILED > 4/-1/?0 - > com/sun/ts/tests/jaxrs/spec/provider/exceptionmapper/JAXRSClient#java > #runtimeExceptionTest_from_standalone - PASSED > 5/-1/?0 - > com/sun/ts/tests/jaxrs/spec/provider/exceptionmapper/JAXRSClient#java > #throwableTest_from_standalone - PASSED > > To run just that failing test in the middle you just need to yank the > "#java" portion and feed that to `./runtests` like so: > > ./runtests -ds -c -w tomee-plume > com/sun/ts/tests/jaxrs/spec/provider/visibility > > > Hope any of the above is helpful! > > -- Richard Zowalla, M.Sc. Research Associate, PhD Student | Medical Informatics Hochschule Heilbronn – University of Applied Sciences Max-Planck-Str. 39 D-74081 Heilbronn phone: +49 7131 504 6791 mail: richard.zowa...@hs-heilbronn.de web: https://www.mi.hs-heilbronn.de/ smime.p7s Description: S/MIME cryptographic signature
Re: Permanently Fixing examples after library upgrades - help wanted
Hi, (a) https://issues.apache.org/jira/browse/TOMEE-3000 (b) I only know the "jira-rest-java-client-core" provided by Atlassian (see https://mvnrepository.com/artifact/com.atlassian.jira/jira-rest-java-client-core/5.2.2 ) - might be worth a try? Sadly, it will only work with the self-hosted Jira Server instance. I do not know, if ASF is using the cloud-hosted approach offered by Atlassian... (c) https://issues.apache.org/jira/browse/TOMEE-3001 Gruss Richard Am Mittwoch, den 07.04.2021, 17:05 -0700 schrieb David Blevins: > > On Apr 6, 2021, at 10:37 AM, Zowalla, Richard < > > richard.zowa...@hs-heilbronn.de> wrote: > > > > Overall, I see some additional things which we should probabily map > > into Jira Issues, so others can participate and grab some issues / > > tasks: > > > > - (a) Run the BOM generation in every build (via exec-maven- > > plugin). > > - (b) Update the other examples to use the BOMs. Organisational > > question: Same procedere as for the translation efforts: Jira issue > > per > > example + overview issue to split the work across many people? > > - (c) Add a not null check in > > TomEESecurityServletAuthenticationMechanismMapper (see [1]) and > > remove > > the exclusion in the related example (as discussed in [1]). > > This looks like a good approach. In the past I used to use a jira > command line tool (swizzle jira) I wrote to file those subtasks of > the parent task. I.e. so things like this were not too difficult: > > - https://issues.apache.org/jira/browse/OPENEJB-142 > > If there was good java client, I could very quickly whip up a nice > CLI with Crest. > > > -David > > > [1] https://github.com/apache/tomee/pull/779#discussion_r607192663 > > > > > > Am Samstag, den 03.04.2021, 16:45 -0700 schrieb David Blevins: > > > > On Apr 3, 2021, at 4:06 PM, Vicente Rossello < > > > > cocorosse...@gmail.com> wrote: > > > > > > > > Nevermind, I saw GenerateBom class before but didn't > > > > remember > > > > So I > > > > guess I can change used xmlsec and wss4j dependencies > > > > everywhere > > > > and > > > > regenerate those BOM, is that correct? > > > > > > That's right. The boms are generated analyzing the actual server > > > zips, so if we want to change a dep in the bom we just need to > > > upgrade the library used in the actual server zips and then > > > regenerate. > > > > > > Ideally we setup GenerateBom to run on every build so people > > > don't > > > have to magically know it's a thing that should be done and how > > > to do > > > it. Looks like Jean-Louis setup the `exec-maven-plugin` in the > > > `tomee-bootstrap` module, but it doesn't seem to be running. > > > > > > Thanks for the PR, Vicente! I'll take a look. > > > > > > > > > -David > > > > > > > > > > On Sun, Apr 4, 2021 at 1:04 AM Vicente Rossello < > > > > cocorosse...@gmail.com> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > May I ask how are those boms generated? > > > > > > > > > > I'm trying to fix "EJB WebService with WS-Security" but what > > > > > I > > > > > can see is > > > > > that CXF is using xmlsec 2.2.1, but BOMs are generated with > > > > > 2.1.4. I'm not > > > > > sure on how to fix this. > > > > > > > > > > I fixed some simple ones in > > > > > https://github.com/apache/tomee/pull/779/files > > > > > > > > > > > > > > > > > > > > Vicente. > > > > > > > > > > > > > > > On Sat, Apr 3, 2021 at 11:43 PM Vicente Rossello < > > > > > cocorosse...@gmail.com> > > > > > wrote: > > > > > > > > > > > Ok, let me take a look at it tomorrow, I'll see what I can > > > > > > do > > > > > > > > > > > > On Sat, Apr 3, 2021 at 9:06 PM David Blevins < > > > > > > david.blev...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Excellent. > > > > > > > > > > > > > > I've just updated the pom generation code to create all > > > > > > > the > > > > > > > "-api" > > > > > > > modules, published snapshots, and tried it out on a > > > > > > > couple > > > > > > > examples: > > > > > > > > > > > > > > TomEE WebProfile example > > > > > > > - > > > > > > > https://github.com/apache/tomee/commit/f0d09e3438036e32b37048968538c38c49ba7d14 > > > > > > > > > > > > > > TomEE MicroProfile example > > > > > > > - > > > > > > > https://github.com/apache/tomee/commit/97f7e4b5038216891b711506689e144d4eae47ae > > > > > > > > > > > > > > Now we just need help updating all the examples like > > > > > > > this. > > > > > > > > > > > > > > Vicente, would you be open to updating the examples that > > > > > > > broke after the > > > > > > > CXF upgrade? Looks like most of them are web service > > > > > > > examples, so the new > > > > > > > tomee-plus-api and tomee-plus dependencies would probably > > > > > > > work. > > > > > > > > > > > > > > - > > > > > > > https://builds.apache.org/job/Tomee/job/master-build-full/137/ > > > > > > > > > > > > > > Anyone else interested in helping out? > > > > > > > > > > > > > > > > > > > > > > > > > > > > -David > > > > > > > > > > > >
Java 16 via 8.0.7-SNAPSHOT - JVM Crash - Any Thoughts?
Hi, I am doing some bleeding edge testing related to JDK/JRE 16 with the latest TomEE 8.0.7-SNAPSHOT as we have included some 3rd party patches, which should support JDK/JRE 16. One remaining thing is OpenJPA, which will support J16 with 3.1.3-SNAPSHOT (so I have patched it in my test). I get this weird JVM crash [1] probably related to LocalBeanProxyFactory when deploying a JSF/JAX-RS WAR archive via the TomEE Maven Plugin. Maybe someone has some thoughts on it (or a hint)? Gruss Richard [1] https://gist.github.com/rzo1/cf70056a0a27d4cb5a714d6211dc7563 smime.p7s Description: S/MIME cryptographic signature
