Re: [EXTERN!]Re: Release TomEE 9.0 final?

[Zowalla, Richard]

No objections. 

Am Mittwoch, dem 21.12.2022 um 10:18 +0100 schrieb Jean-Louis Monteiro:
> No objections. It was also on top of my head to do it before end of
> the
> year.
> 
> 
> I need to look at the failures. I got some exchanges with Tomcat
> folks and
> Tomcat passes the TCK. But they said the tests are badly written and
> unstable.
> 
> 
> 
> Le mer. 21 déc. 2022, 00:35, David Blevins 
> a
> écrit :
> 
> > We have just two failures to deal with and TomEE is then fully
> > Jakarta EE
> > 9.1 and MicroProfile 5.0 compliant.
> > 
> > It would be fantastic to release TomEE 9.0 final as soon as those
> > two
> > failures are resolved so we can start 2023 immediately working on
> > TomEE 10
> > and Jakarta EE 10.
> > 
> > Are there any objections to seeing a TomEE 9.0 final issued as soon
> > as
> > those to tests pass?
> > 
> > 
> > -David
> > 
> > 
-- 
Dr. Richard Zowalla
Research Associate | 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: [Discuss] TomEE 9 Release Candidate?

[Zowalla, Richard]

Hi JL,

+1 - let's roll out an M9 / RC1. 

Feedback from the community is super valuable at this stage.

Gruß
Richard

Am Freitag, dem 28.10.2022 um 10:01 +0200 schrieb Jean-Louis Monteiro:
> Hi all,
> 
> It's been a hard and long journey, but we are there.
> 
> We implemented the last MicroProfile specification and we now pass
> the full
> suite for MicroProfile 5.0.
> 
> We have successfully moved the TomEE server from javax to jakarta to
> support Jakarta EE 9.1. So far, we are 12 tests down from that goal.
> But
> the build is fully fixed and stable now.
> 
> I'm wondering before we claim it final, can we do a release
> candidate. It
> gives us the ability to collect some user feedback. We can also start
> filling MicroProfile compatibility requirements so we can be listed
> as a
> compatible implementation.
> 
> My view is that we could create the final before Christmas as a gift
> and
> move straight to TomEE 10 for Jakarta EE 10. The jump from an end
> user
> point of view will be small, and maybe even invisible. Most of the
> work
> will be on the TCK setup to rethink and redo. The rest is small in
> terms of
> implementation. We should also be able to not only be Web Profile
> certified, but maybe full platform compatible.
> 
> We could also move to MicroProfile 6.0 as now the gap is small. But
> I'll
> probably write another email for this.
> 
> Thoughts?
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: Pull request builds

[Zowalla, Richard]

Hi,

I dropped a message in the builds slack channel to get some thoughts on
our PR issue. Maybe they can give us some hints to docs. 

If the topic is to broad / wide for a quick slack chat, I will sent a
mail to builds@ to get some thoughts / ideas. 

I agree with David, that we cannot be the only project, which suffers
from that issue.

Gruß
Richard


Am Donnerstag, dem 27.10.2022 um 10:38 +0200 schrieb Jean-Louis
Monteiro:
> It only works if you push the PR straight to Apache repo I think
> Richard
> mentioned.
> So every non committer submitting a PR is out of the builder. We need
> to
> ask Infra maybe. I'd be surprised if we would be the first project to
> face
> it.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Thu, Oct 27, 2022 at 12:47 AM David Blevins <
> david.blev...@gmail.com>
> wrote:
> 
> > > On Oct 26, 2022, at 2:13 PM, David Blevins <
> > > david.blev...@gmail.com>
> > wrote:
> > > I wonder if there's some way this can be improved so Richard
> > > doesn't
> > have to create CI jobs for individual PRs.  At minimum, maybe we
> > can have a
> > PR builder job that takes the PR number as a parameter?
> > 
> > I wonder also if there's some way with a Github Action that a
> > committer
> > could comment "test this please" and have that PR build kicked off
> > in
> > Apache's Jenkins?
> > 
> > 
> > -David
> > 
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Website not publishing

[Zowalla, Richard]

Thanks, Swell!

Normal adoc changes (in the generator itself) seem to work, though.

Am Donnerstag, dem 20.10.2022 um 17:08 +0200 schrieb Swell:
> i tested and had a
> 
> Pull Failed. Source{name='tomee-8.0', scmUrl='
> https://github.com/apache/tomee.git', branch='tomee-8.x'}
>   > git pull
> org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout
> conflict
> with files:
> docs/comparison.adoc
> 
> i'll update to do a reset hard on remote instead of pull
> 
> and commit that as a pull request, if it can help
> 
> 
> On Thu, 20 Oct 2022 at 17:06, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Might be related to "master" -> "main" switch a while back.
> > I added a commit, I had already made in my local repository after
> > preparing release notes.
> > 
> > Don't know, if this solves the issue but could be a thing to look
> > at.
> > 
> > Am Donnerstag, dem 20.10.2022 um 16:53 +0200 schrieb Swell:
> > > looked and noticed adoc from only tomee 8.x branch, generated
> > > html
> > > 
> > > looking further.
> > > 
> > > --
> > > Swell
> > > 
> > > On Thu, 20 Oct 2022 at 16:30, David Blevins
> > > 
> > > wrote:
> > > 
> > > > I looked into this about two weeks back for a couple hours but
> > > > didn't
> > > > really find the cause.
> > > > 
> > > > Basically our Jenkins job that builds and publishes the site is
> > > > running,
> > > > but only javadoc is getting produced and not any adoc -> html:
> > > > 
> > > >  - https://ci-builds.apache.org/job/Tomee/job/site-publish/
> > > > 
> > > > I ran the `tomee-site-generator` locally a handful of times and
> > > > it
> > > > also
> > > > fails on my machine, but I ran out of time to debug.
> > > > 
> > > > Posting here so others can investigate if they want -- I'm
> > > > going to
> > > > try
> > > > and focus on the failing JAX-RS tests.
> > > > 
> > > > 
> > > > -David
> > > > 
> > > > 
> > 
> > 



smime.p7s
Description: S/MIME cryptographic signature

Re: Website not publishing

[Zowalla, Richard]

Might be related to "master" -> "main" switch a while back.
I added a commit, I had already made in my local repository after
preparing release notes.

Don't know, if this solves the issue but could be a thing to look at.

Am Donnerstag, dem 20.10.2022 um 16:53 +0200 schrieb Swell:
> looked and noticed adoc from only tomee 8.x branch, generated html
> 
> looking further.
> 
> --
> Swell
> 
> On Thu, 20 Oct 2022 at 16:30, David Blevins 
> wrote:
> 
> > I looked into this about two weeks back for a couple hours but
> > didn't
> > really find the cause.
> > 
> > Basically our Jenkins job that builds and publishes the site is
> > running,
> > but only javadoc is getting produced and not any adoc -> html:
> > 
> >  - https://ci-builds.apache.org/job/Tomee/job/site-publish/
> > 
> > I ran the `tomee-site-generator` locally a handful of times and it
> > also
> > fails on my machine, but I ran out of time to debug.
> > 
> > Posting here so others can investigate if they want -- I'm going to
> > try
> > and focus on the failing JAX-RS tests.
> > 
> > 
> > -David
> > 
> > 



smime.p7s
Description: S/MIME cryptographic signature

Re: TomEE MicroProfile - current status

[Zowalla, Richard]

Hi Zoltan,

the arquillian config is located in
/src/test/java/resources/arquillian.xml.

In this file, you can find a "debug" property, which you can set to
"true" to enable the debug capabilities of TomEE (i.e. start with a
debugger backend).

You can debug single tests by editing "tck-dev.xml" in the module root
directory and adjust the surefire config to use it:

  
tck-dev.xml
  

Hope it helps

Gruß
Richard

Am Donnerstag, dem 20.10.2022 um 09:07 +0200 schrieb Zoltán Tichov:
> Hi!
> 
> I have not been able to solve this problem:
> 
> ERROR: transport error 202: connect failed: Connection refused
> ERROR: JDWP Transport dt_socket failed to initialize,
> TRANSPORT_INIT(510)
> JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports
> initialized
> [./src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:735]
> 
> "Set this property to `true` and it should start TomEE with debug
> enabled
> and listening to port 5005."
> 
> Where should this be set? I looked at the other microprofile TCK
> implementations, but couldn't find a solution
> 
> I managed to activate the opentracing interceptor, but the tests are
> still
> red. I'm still looking for what else needs to be implemented to make
> the
> tests work.
> 
> Thanks:
> 
> Zoltán
> 
> 
> On Tue, Oct 11, 2022 at 6:48 PM David Blevins
> 
> wrote:
> 
> > > On Oct 11, 2022, at 5:53 AM, Zoltán Tichov
> > > 
> > wrote:
> > > 
> > > How to activate the OpenTracingInterceptor from
> > > org.apache.tomee.microprofile.opentracing package?
> > 
> > Set this property to `true` and it should start TomEE with debug
> > enabled
> > and listening to port 5005.
> > 
> > > I think I overestimated my knowledge for this task, so if you
> > > think so, I
> > > would rather pass this task. On the other hand, if there is still
> > > time, I
> > > would like to deal with this.
> > 
> > Take another week and see how far you get.  There's great value in
> > having
> > more people able to help with TCK work.  It's definitely worth it
> > for us
> > all to make the effort to help others get in there and be
> > effective.
> > 
> > Anything but silence is good progress.  Silence is the kiss of
> > death for
> > tasks like this -- just so much knowledge to transfer.  I don't
> > think
> > there's a human being on planet earth who could go from "I want to
> > help get
> > this TCK to pass" to "here's a PR for a passing TCK" and no
> > questions in
> > the middle.
> > 
> > Certainly, I needed a ton of help and I've never met anyone who
> > didn't.
> > 
> > 
> > -David
> > 
> > 



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache TomEE 8.0.13 - First Attempt

[Zowalla, Richard]

Here is my own +1 (binding)

Am Dienstag, dem 11.10.2022 um 19:59 +0200 schrieb Richard Zowalla:
> > Hi all,
> > 
> > this is a first attempt at a vote for a release of Apache TomEE >
> > 8.0.13.
> > 
> > It is a maintenance release with some bug fixes and dependencies
> > upgrades.
> > 
> > ###
> > 
> > Maven Repo:
> > https://repository.apache.org/content/repositories/orgapachetomee-1207
> > 
> >   
> >     
> >   tomee-8.0.13-release-test
> >   Testing TomEE 8.0.13 release candidate
> > 
> > https://repository.apache.org/content/repositories/orgapachetomee-1207
> > 
> >     
> >   
> > 
> > ###
> > 
> > Binaries & Source:
> > 
> > https://dist.apache.org/repos/dist/dev/tomee/staging-1207/tomee-8.0.13/
> > 
> > ###
> > 
> > Tag:
> > 
> > https://github.com/apache/tomee/releases/tag/tomee-project-8.0.13
> > 
> > ###
> > 
> > Latest CI/CD build:
> > 
> > https://ci-builds.apache.org/job/Tomee/job/tomee-8.x-build-full/226/
> > 
> > ###
> > 
> > Release notes:
> > 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12351820
> > 
> > ###
> > 
> > Here is an adoc generated version of the changelog as well:
> > 
> > == Dependency upgrade
> > 
> > [.compact]
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-3985[TOMEE-3985]
> > BatchEE 1.0.2
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4057[TOMEE-4057]
> > CXF 3.4.8
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-3800[TOMEE-3800]
> > DBCP 2.9.0
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4059[TOMEE-4059]
> > EclipseLink 2.7.11
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4063[TOMEE-4063]
> > Geronimo Transaction Manager 3.1.5
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4019[TOMEE-4019]
> > HSQLDB 2.7.0
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-3986[TOMEE-3986]
> > Hibernate Integration 5.6.9.Final
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4042[TOMEE-4042]
> > Jackson 2.13.4
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4067[TOMEE-4067]
> > Jackson 2.14.0-rc1
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4020[TOMEE-4020]
> > Jakarta Faces 2.3.18
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4026[TOMEE-4026]
> > Johnzon 1.2.19
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4030[TOMEE-4030]
> > Log4J2 2.18.0
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-3998[TOMEE-3998]
> > MyFaces 2.3.10
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4044[TOMEE-4044]
> > Snakeyaml 1.32
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4054[TOMEE-4054]
> > Snakeyaml 1.33
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4002[TOMEE-4002]
> > Tomcat 9.0.64
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4051[TOMEE-4051]
> > Tomcat 9.0.65
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4060[TOMEE-4060]
> > Tomcat 9.0.67
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4087[TOMEE-4087]
> > Tomcat 9.0.68
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4018[TOMEE-4018]
> > bcprov-jdk15on 1.70
> > 
> > == New Feature
> > 
> > [.compact]
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-3928[TOMEE-3928]
> > Example for properties provider
> > 
> > == Bug
> > 
> > [.compact]
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4021[TOMEE-4021]
> > Unexpected ehcache 3.8.1 in tomee/lib
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-3850[TOMEE-3850]
> > HTTP(S) connections are not reused
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4014[TOMEE-4014]
> > Unable to see TomEE version in Tomcat home page with Java 17
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-3979[TOMEE-3979]
> > service.bat issue when using JRE_HOME on Windows 
> >  - >
> > link:https://issues.apache.org/jira/browse/TOMEE-4041[TOMEE-4041] 4
> > CVE Vulnerabilities in snakeyaml-1.30.jar 
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4001[TOMEE-4001]
> > CVE-2022-34305 displaying user provided data without filtering, >
> > exposing a XSS vulnerability
> > 
> > == Improvement
> > 
> > [.compact]
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-3878[TOMEE-3878]
> > Backport 'No interface view EJB proxies broken on JDK16+' > [TOMEE-
> > 3877] to TomEE 8.x
> > 
> > == Task
> > 
> > [.compact]
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4064[TOMEE-4064]
> > OpenJPA 3.2.2 (examples), EclipseLink 2.7.11 (examples), Derby >
> > 10.14.2.0
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4022[TOMEE-4022]
> > Move to Apache Rat
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4056[TOMEE-4056]
> > Log4J2 2.19.0
> >  -
> > link:https://issues.apache.org/jira/browse/TOMEE-4058[TOMEE-4058]
> > Update Krazo, DeltaSpike and Hibernate
> >  -
> > 

Re: [VOTE] Apache TomEE 8.0.13 - First Attempt

[Zowalla, Richard]

"or as long as needed" ;-) - waiting for PMC votes.


Am Dienstag, dem 18.10.2022 um 08:36 +0200 schrieb Alex The Rocker:
> Hi here, the vote for TomEE 8.0.13 launched 1 week ago was supposed
> to
> hold for 72 hours...
> Is it still valid or will a new release candidate show up ?
> 
> Alex
> 
> Le dim. 16 oct. 2022 à 08:33, Wiesner, Martin
>  a écrit :
> > 
> > Hi all,
> > 
> > +1 (non-binding)
> > 
> > Tested with several projects (primarily web services, JSF…),
> > both on Linux & Mac OS, each under OpenJDK 17 (latest).
> > 
> > Best
> > Martin
> > —
> > https://twitter.com/mawiesne
> > 
> > 
> > Am 15.10.2022 um 19:41 schrieb Daniel Dias Dos Santos
> > :
> > 
> > Hello,
> > 
> > +1
> > 
> > On Sat, Oct 15, 2022, 14:39 Richard Zowalla 
> > wrote:
> > 
> > Any more votes?
> > 
> > Am Dienstag, dem 11.10.2022 um 19:59 +0200 schrieb Richard Zowalla:
> > 
> > Hi all,
> > 
> > this is a first attempt at a vote for a release of Apache TomEE
> > 8.0.13.
> > 
> > It is a maintenance release with some bug fixes and dependencies
> > upgrades.
> > 
> > ###
> > 
> > Maven Repo:
> > https://repository.apache.org/content/repositories/orgapachetomee-1207
> > 
> >  
> >    
> >  tomee-8.0.13-release-test
> >  Testing TomEE 8.0.13 release candidate
> > 
> > https://repository.apache.org/content/repositories/orgapachetomee-1207
> > 
> >    
> >  
> > 
> > ###
> > 
> > Binaries & Source:
> > 
> > https://dist.apache.org/repos/dist/dev/tomee/staging-1207/tomee-8.0.13/
> > 
> > ###
> > 
> > Tag:
> > 
> > https://github.com/apache/tomee/releases/tag/tomee-project-8.0.13
> > 
> > ###
> > 
> > Latest CI/CD build:
> > 
> > https://ci-builds.apache.org/job/Tomee/job/tomee-8.x-build-full/226/
> > 
> > ###
> > 
> > Release notes:
> > 
> > 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12351820
> > 
> > 
> > ###
> > 
> > Here is an adoc generated version of the changelog as well:
> > 
> > == Dependency upgrade
> > 
> > [.compact]
> > - link:https://issues.apache.org/jira/browse/TOMEE-3985[TOMEE-3985]
> > BatchEE 1.0.2
> > - link:https://issues.apache.org/jira/browse/TOMEE-4057[TOMEE-4057]
> > CXF 3.4.8
> > - link:https://issues.apache.org/jira/browse/TOMEE-3800[TOMEE-3800]
> > DBCP 2.9.0
> > - link:https://issues.apache.org/jira/browse/TOMEE-4059[TOMEE-4059]
> > EclipseLink 2.7.11
> > - link:https://issues.apache.org/jira/browse/TOMEE-4063[TOMEE-4063]
> > Geronimo Transaction Manager 3.1.5
> > - link:https://issues.apache.org/jira/browse/TOMEE-4019[TOMEE-4019]
> > HSQLDB 2.7.0
> > - link:https://issues.apache.org/jira/browse/TOMEE-3986[TOMEE-3986]
> > Hibernate Integration 5.6.9.Final
> > - link:https://issues.apache.org/jira/browse/TOMEE-4042[TOMEE-4042]
> > Jackson 2.13.4
> > - link:https://issues.apache.org/jira/browse/TOMEE-4067[TOMEE-4067]
> > Jackson 2.14.0-rc1
> > - link:https://issues.apache.org/jira/browse/TOMEE-4020[TOMEE-4020]
> > Jakarta Faces 2.3.18
> > - link:https://issues.apache.org/jira/browse/TOMEE-4026[TOMEE-4026]
> > Johnzon 1.2.19
> > - link:https://issues.apache.org/jira/browse/TOMEE-4030[TOMEE-4030]
> > Log4J2 2.18.0
> > - link:https://issues.apache.org/jira/browse/TOMEE-3998[TOMEE-3998]
> > MyFaces 2.3.10
> > - link:https://issues.apache.org/jira/browse/TOMEE-4044[TOMEE-4044]
> > Snakeyaml 1.32
> > - link:https://issues.apache.org/jira/browse/TOMEE-4054[TOMEE-4054]
> > Snakeyaml 1.33
> > - link:https://issues.apache.org/jira/browse/TOMEE-4002[TOMEE-4002]
> > Tomcat 9.0.64
> > - link:https://issues.apache.org/jira/browse/TOMEE-4051[TOMEE-4051]
> > Tomcat 9.0.65
> > - link:https://issues.apache.org/jira/browse/TOMEE-4060[TOMEE-4060]
> > Tomcat 9.0.67
> > - link:https://issues.apache.org/jira/browse/TOMEE-4087[TOMEE-4087]
> > Tomcat 9.0.68
> > - link:https://issues.apache.org/jira/browse/TOMEE-4018[TOMEE-4018]
> > bcprov-jdk15on 1.70
> > 
> > == New Feature
> > 
> > [.compact]
> > - link:https://issues.apache.org/jira/browse/TOMEE-3928[TOMEE-3928]
> > Example for properties provider
> > 
> > == Bug
> > 
> > [.compact]
> > - link:https://issues.apache.org/jira/browse/TOMEE-4021[TOMEE-4021]
> > Unexpected ehcache 3.8.1 in tomee/lib
> > - link:https://issues.apache.org/jira/browse/TOMEE-3850[TOMEE-3850]
> > HTTP(S) connections are not reused
> > - link:https://issues.apache.org/jira/browse/TOMEE-4014[TOMEE-4014]
> > Unable to see TomEE version in Tomcat home page with Java 17
> > - link:https://issues.apache.org/jira/browse/TOMEE-3979[TOMEE-3979]
> > service.bat issue when using JRE_HOME on Windows
> > - link:https://issues.apache.org/jira/browse/TOMEE-4041[TOMEE-4041]
> > 4
> > CVE Vulnerabilities in snakeyaml-1.30.jar
> > - link:https://issues.apache.org/jira/browse/TOMEE-4001[TOMEE-4001]
> > CVE-2022-34305 displaying user provided data without filtering,
> > exposing a XSS vulnerability
> > 
> > == Improvement
> > 
> > [.compact]
> > - link:https://issues.apache.org/jira/browse/TOMEE-3878[TOMEE-3878]

Re: [HELP] Build times for Infra

[Zowalla, Richard]

Hi,

I am starting this test on a virtual machine in our infra now.

@all For building main you need to either use a JDK 11 or JDK 17. This
information is also relevant as well as the Maven version used to for
building.

In addition, it might be required to switch the git repo url in the sh
script from the ssh-based to the http based version (
https://github.com/apache/tomee.git), so you can run on a dedicated
machine in which you do not need to setup private/public key auth.

Gruß
Richard

Am Dienstag, dem 11.10.2022 um 15:05 -0700 schrieb David Blevins:
> All,
> 
> I'm collecting some stats on how long it takes to run our full build
> exactly as Jenkins does.  The goal is to work with them to see if we
> can get some better hardware -- I assume that will require donations,
> etc.
> 
> If you'd like to help in collecting data, here's the script I'm
> running:
> 
> - curl 
> https://gist.githubusercontent.com/dblevins/b39cc3300bcdd89b426ca33b87b5452b/raw/7c68d4df71e9246c8bf2d0a741f8b145ca5d0820/buildtime.sh
> | bash
> 
> Send the time reported in the build.log along with your system
> information (os, number of cores, if you disk is an SSD, etc)
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache TomEE 8.0.13 - First Attempt

[Zowalla, Richard]

Hi Alex,

I can confirm, that 2.14.0-rc1 fixes the vulnerability as I cherry-
picked the related fixes to an upcoming 2.13.4.1 (micro patch version)
yesterday. My PR was merged in earlier today.

The issue is, that the fix version is set to 2.14.0 in the CVE itself
although it is included in 2.14.0-rc1. This is due to the fact, that
the jackson people do not want a widespread use of rc1 due to the
security vulnerability as it only affectes users if
'UNWRAP_SINGLE_VALUE_ARRAYS' is set to enabled. 

I can add a related sentence to the release notes. In addition, I will
add a statement regarding hsqldb 2.7.1, which doesn't show up in grype
at all.

Gruß
Richard



Am Mittwoch, dem 12.10.2022 um 08:49 +0200 schrieb Alex The Rocker:
> Hello Again,
> 
> Completed some basic tests with TomEE+ 8.0.13 (more complex tests to
> come), but also I ran https://github.com/anchore/grype latest version
> on TomEE+ 8.0.12 versus this candidate 8.0.13, with focus on Jackson
> CVEs, and here's the outcome:
> 
> With TomEE+ 8.0.12, the jackson-databind-2.13.2.2.jar file was found
> to have the following vulnerabilities:
> CVE-2022-42003
> CVE-2022-42004
> GHSA-jjjh-jjxp-wpff
> GHSA-rgv9-q543-rqg4
> 
> With TomEE+ 8.0.13 candidate release, jackson-databind-2.14.0-rc1.jar
> file file was found to have the following vulnerabilities:
> CVE-2022-42003
> 
> which is bizarre because according to
> https://nvd.nist.gov/vuln/detail/CVE-2022-42003, 2.14.0-rc1 is
> supposed to fix CVE-2022-42003.
> 
> I know that Grype isn't perfect, but problem is that it is widely
> used, so if you are sure that this is a false positive, then can you
> please provide a statement about it in release notes and/or in
> documentation, to avoid users' confusion?
> 
> PS: CVE-2022-42003 is rated 7.5 (High) by
> https://nvd.nist.gov/vuln/detail/CVE-2022-42003, so it's not quite
> TomEE 8.0.13 could be released without a word about it...
> 
> I will send my vote when I'll have completed my more advanced tests
> with 8.0.13 candidate release.
> 
> Thanks,
> Alex
> 
> Le mar. 11 oct. 2022 à 22:28, Zowalla, Richard
>  a écrit :
> > Good catch. This is expected:
> > 
> > https://issues.apache.org/jira/browse/TOMEE-4021
> > 
> > or
> > 
> > https://lists.apache.org/thread/8tky9dr2sf99cs2hrj95j81w1rhrtdfn
> > 
> > Gruß
> > Richard
> > 
> > Am Dienstag, dem 11.10.2022 um 22:23 +0200 schrieb Alex The Rocker:
> > > okay I probably make a mistake somewhere.
> > > Also I see ehcache*.jar is removed in TomEE+ 8.0.13 => is it
> > > intentional (I love seeing less JARs;) ?
> > > 
> > > Alex
> > > 
> > > Le mar. 11 oct. 2022 à 22:17, Zowalla, Richard
> > >  a écrit :
> > > > I am currently not on my dev system but I checked via:
> > > > 
> > > > $ gpg --batch --keyserver hkp://keyserver.ubuntu.com:80 --recv-
> > > > keys
> > > > B83D15E72253ED1104EB4FBBDAB472F0E5B8A431
> > > > 
> > > > $ gpg --verify apache-tomee-8.0.13-plus.tar.gz.asc apache-
> > > > tomee-
> > > > 8.0.13-
> > > > plus.tar.gz
> > > > 
> > > > gpg: Signatur vom Di 11 Okt 2022 13:14:04 CEST
> > > > gpg:mittels RSA-Schlüssel
> > > > B83D15E72253ED1104EB4FBBDAB472F0E5B8A431
> > > > gpg: Korrekte Signatur von "Richard Zowalla (Code Signing Key)
> > > > " [unbekannt]
> > > > 
> > > > 
> > > > Gruß
> > > > Richard
> > > > 
> > > > Am Dienstag, dem 11.10.2022 um 22:04 +0200 schrieb Alex The
> > > > Rocker:
> > > > > Sorry previous mail sent too quickly.
> > > > > 
> > > > > What's wrong here ?
> > > > > 
> > > > > $ gpg --verify /tmp/tomee8013.asc apache-tomee-8.0.13-
> > > > > plus.tar.gz
> > > > > gpg: Signature made Tue 11 Oct 2022 01:14:04 PM CEST using
> > > > > RSA
> > > > > key ID
> > > > > E5B8A431
> > > > > gpg: Can't check signature: No public key
> > > > > 
> > > > > Le mar. 11 oct. 2022 à 22:03, Alex The Rocker
> > > > > 
> > > > > a écrit :
> > > > > > Hum... what's wrong here:
> > > > > > 
> > > > > > Le mar. 11 oct. 2022 à 21:22, Alex The Rocker
> > > > > >  a écrit :
> > > > > > > +1 for more frequent releases (at least based on CVE with
> > > > > > > at
> > > > > > &g

Re: [VOTE] Apache TomEE 8.0.13 - First Attempt

[Zowalla, Richard]

Good catch. This is expected: 

https://issues.apache.org/jira/browse/TOMEE-4021

or 

https://lists.apache.org/thread/8tky9dr2sf99cs2hrj95j81w1rhrtdfn

Gruß
Richard

Am Dienstag, dem 11.10.2022 um 22:23 +0200 schrieb Alex The Rocker:
> okay I probably make a mistake somewhere.
> Also I see ehcache*.jar is removed in TomEE+ 8.0.13 => is it
> intentional (I love seeing less JARs;) ?
> 
> Alex
> 
> Le mar. 11 oct. 2022 à 22:17, Zowalla, Richard
>  a écrit :
> > 
> > I am currently not on my dev system but I checked via:
> > 
> > $ gpg --batch --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys
> > B83D15E72253ED1104EB4FBBDAB472F0E5B8A431
> > 
> > $ gpg --verify apache-tomee-8.0.13-plus.tar.gz.asc apache-tomee-
> > 8.0.13-
> > plus.tar.gz
> > 
> > gpg: Signatur vom Di 11 Okt 2022 13:14:04 CEST
> > gpg:    mittels RSA-Schlüssel
> > B83D15E72253ED1104EB4FBBDAB472F0E5B8A431
> > gpg: Korrekte Signatur von "Richard Zowalla (Code Signing Key)
> > " [unbekannt]
> > 
> > 
> > Gruß
> > Richard
> > 
> > Am Dienstag, dem 11.10.2022 um 22:04 +0200 schrieb Alex The Rocker:
> > > Sorry previous mail sent too quickly.
> > > 
> > > What's wrong here ?
> > > 
> > > $ gpg --verify /tmp/tomee8013.asc apache-tomee-8.0.13-plus.tar.gz
> > > gpg: Signature made Tue 11 Oct 2022 01:14:04 PM CEST using RSA
> > > key ID
> > > E5B8A431
> > > gpg: Can't check signature: No public key
> > > 
> > > Le mar. 11 oct. 2022 à 22:03, Alex The Rocker
> > > 
> > > a écrit :
> > > > 
> > > > Hum... what's wrong here:
> > > > 
> > > > Le mar. 11 oct. 2022 à 21:22, Alex The Rocker
> > > >  a écrit :
> > > > > 
> > > > > +1 for more frequent releases (at least based on CVE with at
> > > > > least
> > > > > high severity)
> > > > > and yes, I have a relatively large test base ; stay tuned!
> > > > > 
> > > > > Le mar. 11 oct. 2022 à 21:16, Richard Zowalla
> > > > >  a
> > > > > écrit :
> > > > > > 
> > > > > > Hi Alex,
> > > > > > 
> > > > > > we can maybe get into the habit of realising more often
> > > > > > (yes, I
> > > > > > know:
> > > > > > we discussed this over and over on the list...).
> > > > > > 
> > > > > > I was just copying from the VOTE template docs, which
> > > > > > mention
> > > > > > to write
> > > > > > "first attempt" and so on... - so no regrets just copy &
> > > > > > paste.
> > > > > > 
> > > > > > I don't expect any suprises but we never know: I did some
> > > > > > tests
> > > > > > on some
> > > > > > of our projects (jaxrs, jaxws, batche, ...) but I have no
> > > > > > possibility
> > > > > > to do large scale tests as you can do them ;-) - so happy
> > > > > > to
> > > > > > get some
> > > > > > feedback.
> > > > > > 
> > > > > > The CXF cleanup might be a candidate for regressions as we
> > > > > > shipped
> > > > > > older code under the covers of newer cxf versions and
> > > > > > didn't
> > > > > > notice
> > > > > > that for some time now.
> > > > > > 
> > > > > > Gruß
> > > > > > Richard
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Am Dienstag, dem 11.10.2022 um 21:05 +0200 schrieb Alex The
> > > > > > Rocker:
> > > > > > > Hi Richard,
> > > > > > > 
> > > > > > > Thanks for this quick TomEE 8.0.3 release after not so
> > > > > > > long
> > > > > > > discussions!
> > > > > > > I'll run some tests ASAP and then give my vote (non-
> > > > > > > binding).
> > > > > > > Why do you mention "1st attempt"? Any regrets ?
> > > > > > > 
> > > > > > > Alex
> > > > > > > 
> > > > > > > Le mar. 11 oct. 2022 à 20:01, Richard Zowalla
> > > > > > >  a
&

Re: [VOTE] Apache TomEE 8.0.13 - First Attempt

[Zowalla, Richard]

I am currently not on my dev system but I checked via:

$ gpg --batch --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys
B83D15E72253ED1104EB4FBBDAB472F0E5B8A431

$ gpg --verify apache-tomee-8.0.13-plus.tar.gz.asc apache-tomee-8.0.13-
plus.tar.gz

gpg: Signatur vom Di 11 Okt 2022 13:14:04 CEST
gpg:mittels RSA-Schlüssel
B83D15E72253ED1104EB4FBBDAB472F0E5B8A431
gpg: Korrekte Signatur von "Richard Zowalla (Code Signing Key)
" [unbekannt]


Gruß
Richard

Am Dienstag, dem 11.10.2022 um 22:04 +0200 schrieb Alex The Rocker:
> Sorry previous mail sent too quickly.
> 
> What's wrong here ?
> 
> $ gpg --verify /tmp/tomee8013.asc apache-tomee-8.0.13-plus.tar.gz
> gpg: Signature made Tue 11 Oct 2022 01:14:04 PM CEST using RSA key ID
> E5B8A431
> gpg: Can't check signature: No public key
> 
> Le mar. 11 oct. 2022 à 22:03, Alex The Rocker 
> a écrit :
> > 
> > Hum... what's wrong here:
> > 
> > Le mar. 11 oct. 2022 à 21:22, Alex The Rocker
> >  a écrit :
> > > 
> > > +1 for more frequent releases (at least based on CVE with at
> > > least
> > > high severity)
> > > and yes, I have a relatively large test base ; stay tuned!
> > > 
> > > Le mar. 11 oct. 2022 à 21:16, Richard Zowalla  a
> > > écrit :
> > > > 
> > > > Hi Alex,
> > > > 
> > > > we can maybe get into the habit of realising more often (yes, I
> > > > know:
> > > > we discussed this over and over on the list...).
> > > > 
> > > > I was just copying from the VOTE template docs, which mention
> > > > to write
> > > > "first attempt" and so on... - so no regrets just copy & paste.
> > > > 
> > > > I don't expect any suprises but we never know: I did some tests
> > > > on some
> > > > of our projects (jaxrs, jaxws, batche, ...) but I have no
> > > > possibility
> > > > to do large scale tests as you can do them ;-) - so happy to
> > > > get some
> > > > feedback.
> > > > 
> > > > The CXF cleanup might be a candidate for regressions as we
> > > > shipped
> > > > older code under the covers of newer cxf versions and didn't
> > > > notice
> > > > that for some time now.
> > > > 
> > > > Gruß
> > > > Richard
> > > > 
> > > > 
> > > > 
> > > > Am Dienstag, dem 11.10.2022 um 21:05 +0200 schrieb Alex The
> > > > Rocker:
> > > > > Hi Richard,
> > > > > 
> > > > > Thanks for this quick TomEE 8.0.3 release after not so long
> > > > > discussions!
> > > > > I'll run some tests ASAP and then give my vote (non-binding).
> > > > > Why do you mention "1st attempt"? Any regrets ?
> > > > > 
> > > > > Alex
> > > > > 
> > > > > Le mar. 11 oct. 2022 à 20:01, Richard Zowalla
> > > > >  a
> > > > > écrit :
> > > > > > Hi all,
> > > > > > 
> > > > > > this is a first attempt at a vote for a release of Apache
> > > > > > TomEE
> > > > > > 8.0.13.
> > > > > > 
> > > > > > It is a maintenance release with some bug fixes and
> > > > > > dependencies
> > > > > > upgrades.
> > > > > > 
> > > > > > ###
> > > > > > 
> > > > > > Maven Repo:
> > > > > > https://repository.apache.org/content/repositories/orgapachetomee-1207
> > > > > > 
> > > > > >   
> > > > > >     
> > > > > >   tomee-8.0.13-release-test
> > > > > >   Testing TomEE 8.0.13 release candidate
> > > > > > 
> > > > > > https://repository.apache.org/content/repositories/orgapachetomee-1207
> > > > > > 
> > > > > >     
> > > > > >   
> > > > > > 
> > > > > > ###
> > > > > > 
> > > > > > Binaries & Source:
> > > > > > 
> > > > > > https://dist.apache.org/repos/dist/dev/tomee/staging-1207/tomee-8.0.13/
> > > > > > 
> > > > > > ###
> > > > > > 
> > > > > > Tag:
> > > > > > 
> > > > > > https://github.com/apache/tomee/releases/tag/tomee-project-8.0.13
> > > > > > 
> > > > > > ###
> > > > > > 
> > > > > > Latest CI/CD build:
> > > > > > 
> > > > > > https://ci-builds.apache.org/job/Tomee/job/tomee-8.x-build-full/226/
> > > > > > 
> > > > > > ###
> > > > > > 
> > > > > > Release notes:
> > > > > > 
> > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12351820
> > > > > > 
> > > > > > ###
> > > > > > 
> > > > > > Here is an adoc generated version of the changelog as well:
> > > > > > 
> > > > > > == Dependency upgrade
> > > > > > 
> > > > > > [.compact]
> > > > > >  - link:
> > > > > > https://issues.apache.org/jira/browse/TOMEE-3985[TOMEE-3985]
> > > > > > BatchEE 1.0.2
> > > > > >  - link:
> > > > > > https://issues.apache.org/jira/browse/TOMEE-4057[TOMEE-4057]
> > > > > > CXF 3.4.8
> > > > > >  - link:
> > > > > > https://issues.apache.org/jira/browse/TOMEE-3800[TOMEE-3800]
> > > > > > DBCP 2.9.0
> > > > > >  - link:
> > > > > > https://issues.apache.org/jira/browse/TOMEE-4059[TOMEE-4059]
> > > > > > EclipseLink 2.7.11
> > > > > >  - link:
> > > > > > https://issues.apache.org/jira/browse/TOMEE-4063[TOMEE-4063]
> > > > > > Geronimo Transaction Manager 3.1.5
> > > > > >  - link:
> > > > > > https://issues.apache.org/jira/browse/TOMEE-4019[TOMEE-4019]
> > > > > > HSQLDB 2.7.0
> > > > > >  - link:
> > > > > > 

Re: Pull request builds

[Zowalla, Richard]

Perhaps worth a mail to build@ ?

I can't imagine that others do not run into same issues related to
random number generations / entropy issues.

Gruß
Richard

Am Dienstag, dem 11.10.2022 um 17:50 +0200 schrieb Jean-Louis Monteiro:
> Yes you are correct. This is a possible problem.
> 
> Digging down a bit
> 
>  TomEE :: TCK :: MicroProfile Config TCK 1 mn 38
> s
>  TomEE :: TCK :: MicroProfile Fault Tolerance TCK   1 h 11 mn
>  TomEE :: TCK :: MicroProfile Health TCK 5 mn 6 s
>  TomEE :: iTests :: MicroProfile JWT  11
> mn
>  TomEE :: TCK :: MicroProfile JWT TCK1 mn 50
> s
>  TomEE :: TCK :: MicroProfile Metrics TCK45 mn
>  TomEE :: TCK :: MicroProfile Open API TCK   8 mn 21 s
>  TomEE :: TCK :: MicroProfile Rest Client TCK 4 mn 8 s
> 
> I'm running them all locally to get a taste of how long they actually
> should take in an ideal world. So we have some more materials to
> reach out
> to infra.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Tue, Oct 11, 2022 at 5:42 PM David Blevins <
> david.blev...@gmail.com>
> wrote:
> 
> > > On Oct 11, 2022, at 2:33 AM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> > > I can't measure without investing a lot of time, but looking at
> > > what
> > Maven
> > > reports
> > > CDI + BVal TCK around 25 min
> > > MicroProfile TCK 2 hours and a half
> > 
> > There's definitely something going on with the build machines as
> > the
> > MicroProfile TCK takes 1 or 2 minutes on my machine.
> > 
> > I've seen issues before where the random number generator runs out
> > of
> > entropy and basically stops any call to SecureRandom for several
> > minutes
> > while it just sits there and waits for more random numbers to be
> > generated.
> > 
> > With all the signing and encryption in the MicroProfile TCK, I bet
> > that's
> > what's going on.  Not too sure what options we might have.
> > 
> > We'd probably need something very simple we could use to show infra
> > and
> > work with them on a solution.
> > 
> > -David
> > 
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Pull request builds

[Zowalla, Richard]

Hi,

The INFRA docs [1] do not mention any constraint that the PR needs to
come from the same repository. 

It is also a problem, that we need to rely on different versions of
Java based on a given branch, i.e. Java 8 for 8.x and Java 11 for 9.x,
etc - there is no easy way to decide which one to use for the naive PR
builder job.

It might be possible, that there is a restriction regarding the GitHub
Apache org members due to security concerns? 

For example: https://github.com/apache/tomee/pull/782 did build on the
PR builder but the branch did not reside inside the ASF repo but was
located in my fork.

Sadly our full build takes too long for GH actions...

Gruß
Richard

[1] 
https://cwiki.apache.org/confluence/display/INFRA/Kicking+off+a+Jenkins+build+with+a+GitHub+PR


Am Montag, dem 10.10.2022 um 09:57 -0500 schrieb David Blevins:
> Was putting some thoughts into how we can maybe keep the build more
> stable.
> 
> One obstacle seems to be that the PR builder doesn't build PRs unless
> they're coming from branches inside the apache/tomee.git repo, not
> branches from a fork.  Is anyone else seeing the same thing or have
> any information there?
> 
> If there is some kind of limitation for that plugin, maybe we need to
> setup a git branch for each person who regularly submits PRs?
> 
> Brainstorming at this point.  Any thoughts?
> 
> 
> -David
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: TomEE Jakarta and CXF

[Zowalla, Richard]

> One thing we need to start removing for TomEE 10 is all the shading
> operations we do on various libraries, CXF being one of them. They
make
>TomEE development harder and also break dependency management.

+1 - it is definitley a pain ;) 

Am Montag, dem 10.10.2022 um 10:28 +0200 schrieb Jean-Louis Monteiro:
> Hi,
> 
> As I mentioned, I started debugging some TCK failures with CXF, but
> the
> learning curve and the JAX-RS specification and CXF stack is a big of
> a
> challenge.
> 
> So I also tried master because it moved to jakarta, but I have the
> same
> feedback and concerns that you mentioned David. I don't think it's a
> good
> option for TomEE 9. Maybe for 10 that would be great.
> 
> One thing we need to start removing for TomEE 10 is all the shading
> operations we do on various libraries, CXF being one of them. They
> make
> TomEE development harder and also break dependency management.
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Sat, Oct 8, 2022 at 5:51 PM David Blevins  >
> wrote:
> 
> > Just checked in on where CXF 4.0 is at in the development
> > cycle.  This is
> > the version that implements the jakarta namespace.  High level:
> > 
> >  - Still heavy development
> >  - No milestone releases
> >  - Targeting Java 17
> >  - Targeting Jakarta Rest 3.0
> > 
> > It's a little tricky to know in which TomEE version we could use
> > that.
> > TomEE 9 is Java 11 and above, so the Java 17 requirement rules out
> > using
> > CXF 4.0 -- as does the timeline, really.  TomEE 10 would be Jakarta
> > 10 &
> > Java 17 focused, but there we'd need Jakarta Rest 3.1, not 3.0.
> > 
> > Given we're nearly at the finish line with TomEE 9, I suspect the
> > best
> > outcome for us would be that CXF 4.0 jumps to Jakarta Rest 3.1
> > (with our
> > help of course).
> > 
> > Thoughts?
> > 
> > 
> > -David
> > 
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] TomEE 8.0.13 - How do we want to deal with pending CVEs / patch versions?

[Zowalla, Richard]

> TomEE 8.0.12 is already affected by these 2 CVE, right?

Yes (+ some others as discussed in the 'Cut a 8.0.13' thread).

Gruß
Richard

Am Sonntag, dem 09.10.2022 um 10:59 +0200 schrieb Swell:
> TomEE 8.0.12 is already affected by these 2 CVE, right?
> 
> i am unsure in terms of corporate image.
> no-shipping and waiting seems a bit hard on clients who would need to
> have
> tech-watch and/or security teams to update the jars by themselves in
> production.
> 
> it would be great to provide counter mesures when there are, maybe
> ship
> asap so clients have them:
> jackson (a) shipping even RC (more stable than milestone)
> hsqldb (b) the script flags, but with work to do next time to remove
> them
> and update deps.
> + release note.
> 
> that's more job on TomEE contributors side but clients may be happy
> about
> transparency and counter mesures provided? even more if 8.0.12 is
> already
> affected.
> ops/security people always read the release notes, right?
> 
> another point of view is we are not responsible for other software
> CVEs and
> security teams should always be prepared to update things like the os
> and
> stuff including libraries.
> 
> two shippings in 2 months seems fair, but i'm not the one doing the
> releases. :-)
> 
> have a nice Sunday!
> --
> Swell
> 
> On Sun, 9 Oct 2022 at 09:44, Richard Zowalla  wrote:
> 
> > Hi all,
> > 
> > I think, that we are soon in a good state to do a 8.0.13.
> > 
> > However, there are some open points for which I want to get the
> > community's opinion.
> > 
> > # (1): CVE-2022-42003 (jackson-databind)
> > 
> > Were is one CVE related to jackson-databind:
> > 
> > https://nvd.nist.gov/vuln/detail/CVE-2022-42003 (before 2.14.0-rc1)
> > 
> > Users are only affected, if 'UNWRAP_SINGLE_VALUE_ARRAYS' is set to
> > enabled [1]. AFAIK, we do not enable that feature by default.
> > 
> > There is an ongoing discussion about 2.14.0 final on their list but
> > it
> > seems that it will be late October / mid November until they will
> > release that artifact.
> > 
> > Question(s) to discuss is:
> > 
> > (a) Do we want to ship a release with a RC version?
> > (b) Do we want to wait for 2.14.0.Final?
> > (c) Do we want to ship with 2.13.4 instead + adding a related
> > section
> > to our release notes?
> > 
> > # (2): CVE-2022-41853 (hsqldb)
> > 
> > In addition, were is CVE-2022-41853, which affects HSQLDB < 2.7.1.
> > 2.7.1 isn't available yet [2]. A workaround is to set a related
> > sytsem
> > property to mitigate the behaviour.
> > 
> > Question(s) to discuss is:
> > 
> > (a) Do we want to wait for a 2.7.1 release before doing 8.0.13
> > (AFAIK,
> > no ETA yet)
> > (b) Add the workaround (via java args) to our startup scripts and
> > go
> > for the release
> > (c) Ship with 2.7.0 + adding a related section to our release
> > notes?
> > 
> > Keep in mind: If we do not update to the "official" fix version
> > (even
> > if we add related infos on our release note or mitigate via the
> > official workaround), automated security scanners will complain
> > about
> > it and ops / security people will wonder about it.
> > 
> > Happy to receive feedback on these questions, so we can continue.
> > 
> > Gruß
> > Richard
> > 
> > 
> > 
> > 
> > [1]
> > 
> > https://github.com/FasterXML/jackson/discussions/126#discussioncomment-3815395
> > [2] https://github.com/advisories/GHSA-77xx-rxvh-q682
> > 
> > 
> > 
> > 
> > 



smime.p7s
Description: S/MIME cryptographic signature

Re: TOMEE-4010 - Upgrade xmlsec to 3.0.0

[Zowalla, Richard]

Quick follow up on that one:

(1) I did the revert, i.e. the example should work now.

(2) The next version of wss4j (3.0.x) seems to support the method
signature changes of xmlsec/santuario as they internally upgraded.
Their release is under vote [1] and needs to get picked up by cxf in
the chain. 

Gruß
Richard

[1] https://lists.apache.org/thread/rzww6qqt06wmvcf9hv607o63ddm8mzzt

Am Samstag, dem 08.10.2022 um 11:33 + schrieb Zowalla, Richard:
> Hi David,
> 
> good catch! Looks like we didn't were that far with the build in
> July,
> so didn't notice that one :)
> 
> It looks like CXF 3.5.x depends on xmslec 2.3.0 - I tested it with
> 2.3.0, but no luck either. Needs some digging, upgrade / patching.
> 
> For now, I will revert the upgrade commit to the previous version
> (2.2.3) on main and cleanup jira accordingly + leave some information
> in the related tickets, so I can do some digging in cxf, wss4j, etc.
> later. That thing shouldn't block our efforts in stabilizing the
> build.
> 
> 
> Gruß
> Richard
> 
> 
> 
> Am Samstag, dem 08.10.2022 um 02:23 -0500 schrieb David Blevins:
> > FYI this upgrade is what is breaking `examples/webservice-ws-
> > security`
> > 
> > The version 2.2.3 or 2.2.4 will cause the example's test to
> > pass.  The version 3.0.0 causes the failure due to missing method
> > signature.  I also tried 2.3.2, but no luck.
> > 
> > I didn't revert as I figured Richard might have some preferences on
> > how to proceed.  Looks like either a CXF patch or a downgrade and
> > jira cleanup would work.
> > 
> > 
> > -David
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: TOMEE-4010 - Upgrade xmlsec to 3.0.0

[Zowalla, Richard]

Hi David,

good catch! Looks like we didn't were that far with the build in July,
so didn't notice that one :)

It looks like CXF 3.5.x depends on xmslec 2.3.0 - I tested it with
2.3.0, but no luck either. Needs some digging, upgrade / patching.

For now, I will revert the upgrade commit to the previous version
(2.2.3) on main and cleanup jira accordingly + leave some information
in the related tickets, so I can do some digging in cxf, wss4j, etc.
later. That thing shouldn't block our efforts in stabilizing the build.


Gruß
Richard



Am Samstag, dem 08.10.2022 um 02:23 -0500 schrieb David Blevins:
> FYI this upgrade is what is breaking `examples/webservice-ws-
> security`
> 
> The version 2.2.3 or 2.2.4 will cause the example's test to
> pass.  The version 3.0.0 causes the failure due to missing method
> signature.  I also tried 2.3.2, but no luck.
> 
> I didn't revert as I figured Richard might have some preferences on
> how to proceed.  Looks like either a CXF patch or a downgrade and
> jira cleanup would work.
> 
> 
> -David
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Cut a 8.0.13?

[Zowalla, Richard]

Ok - judging from the changelog of bval 2.0.6, there isn't that much
different aside from the jakarta migrations.

I will - for now - revert the upgrade on 8.x back to 2.0.5, document
the issue and we can come back to it later again.


Am Donnerstag, dem 06.10.2022 um 17:00 +0200 schrieb Jean-Louis
Monteiro:
> I'm fully focused on TomEE 9 at the moment. I'll have a look to the
> BVal
> failure though in case it comes to my mind.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Thu, Oct 6, 2022 at 2:31 PM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Hi,
> > 
> > a short update here. Looks like we are +1 for doing a release
> > rather
> > soon than later.
> > 
> > Swell and myself did some dependency updates in the last days.
> > 
> > I think, that we are in a good shape soon but need to address the
> > following things:
> > 
> > (A) BVAL 2.0.6
> > 
> > Currently, we have one bval tck test failing in TomEE, which is
> > similar
> > to [1]. I asked JL on Slack for help as he seems to be the person
> > who
> > solved it in [1]. Otherwise, we  might revert the upgrade.
> > 
> > (B) TOMEE-4066
> > 
> > Jackson seems to be affected by CVE-2022-42004 and CVE-2022-42003.
> > The
> > latter requires 2.14.0-rc1 as a fixed version. 2.14.0 final is
> > planned
> > for mid october [2], so we either ship with rc1 or wait until mid
> > october.
> > 
> > Gruß
> > Richard
> > 
> > 
> > 
> > [1] https://www.mail-archive.com/dev@tomee.apache.org/msg14542.html
> > [2]
> > https://groups.google.com/g/jackson-dev/c/RuiMDNM3vpQ/m/FgLnTxBPAwAJ
> > 
> > 
> > Am Donnerstag, dem 29.09.2022 um 10:22 +0100 schrieb Jonathan
> > Gallimore:
> > > +1. And yes, this willinclude the fix to mitigate CVE-2021-43980.
> > > 
> > > Jon
> > > 
> > > On Wed, Sep 28, 2022 at 6:45 PM Alex The Rocker <
> > > alex.m3...@gmail.com
> > > wrote:
> > > 
> > > > Hi there,
> > > > 
> > > > +1 for a TomEE 8.013 ASAP provided it includes fix for:
> > > > 
> > > > CVE-2021-43980 Apache Tomcat - Information Disclosure
> > > > 
> > > > Kind regards,
> > > > Alex
> > > > 
> > > > Le mer. 28 sept. 2022 à 18:45, Zowalla, Richard
> > > >  a écrit :
> > > > > Hi all,
> > > > > 
> > > > > our last 8.x release was in June and we have 22 pending
> > > > > updates/issues
> > > > > for 8.0.13. Mostly dependency updates (johnzon, dbcp2,
> > > > > myfaces,
> > > > > hsqldb,
> > > > > tomcat, jakarta faces), and some minor bugs (windows, jdk17+
> > > > > related
> > > > > backports), see below.
> > > > > 
> > > > > We might need to go through the 3rd party libs again and see,
> > > > > if
> > > > > there
> > > > > are additional updates we might want to include.
> > > > > 
> > > > > Would be worth to do a release soon (Mid/End of October?),
> > > > > imho.
> > > > > 
> > > > > Is there anything else we should include / patch before doing
> > > > > a
> > > > > 8.0.13?
> > > > > Any objections?
> > > > > 
> > > > > Wdyt?
> > > > > 
> > > > > Gruß
> > > > > Richard
> > > > > 
> > > > > 
> > > > > == Dependency upgrade
> > > > > 
> > > > > [.compact]
> > > > >  - link:
> > > > > https://issues.apache.org/jira/browse/TOMEE-3985[TOMEE-3985]
> > > > BatchEE 1.0.2
> > > > >  - link:
> > > > > https://issues.apache.org/jira/browse/TOMEE-3800[TOMEE-3800]
> > > > DBCP 2.9.0
> > > > >  - link:
> > > > > https://issues.apache.org/jira/browse/TOMEE-3986[TOMEE-3986]
> > > > Hibernate Integration 5.6.9.Final
> > > > >  - link:
> > > > > https://issues.apache.org/jira/browse/TOMEE-4042[TOMEE-4042]
> > > > Jackson 2.13.4
> > > > >  - link:
> > > > > https://issues.apache.org/jira/browse/TOMEE-4020[TOMEE-4020]
> > > > Jakarta Faces 2.3.18
> > > > >  - link:
> > > > > https://issues.apache.org/jira/browse/TOMEE-4026[

Re: Cut a 8.0.13?

[Zowalla, Richard]

Hi,

a short update here. Looks like we are +1 for doing a release rather
soon than later.

Swell and myself did some dependency updates in the last days.

I think, that we are in a good shape soon but need to address the
following things:

(A) BVAL 2.0.6

Currently, we have one bval tck test failing in TomEE, which is similar
to [1]. I asked JL on Slack for help as he seems to be the person who
solved it in [1]. Otherwise, we  might revert the upgrade.

(B) TOMEE-4066

Jackson seems to be affected by CVE-2022-42004 and CVE-2022-42003. The
latter requires 2.14.0-rc1 as a fixed version. 2.14.0 final is planned
for mid october [2], so we either ship with rc1 or wait until mid
october.

Gruß
Richard



[1] https://www.mail-archive.com/dev@tomee.apache.org/msg14542.html
[2] 
https://groups.google.com/g/jackson-dev/c/RuiMDNM3vpQ/m/FgLnTxBPAwAJ


Am Donnerstag, dem 29.09.2022 um 10:22 +0100 schrieb Jonathan
Gallimore:
> +1. And yes, this willinclude the fix to mitigate CVE-2021-43980.
> 
> Jon
> 
> On Wed, Sep 28, 2022 at 6:45 PM Alex The Rocker  >
> wrote:
> 
> > Hi there,
> > 
> > +1 for a TomEE 8.013 ASAP provided it includes fix for:
> > 
> > CVE-2021-43980 Apache Tomcat - Information Disclosure
> > 
> > Kind regards,
> > Alex
> > 
> > Le mer. 28 sept. 2022 à 18:45, Zowalla, Richard
> >  a écrit :
> > > Hi all,
> > > 
> > > our last 8.x release was in June and we have 22 pending
> > > updates/issues
> > > for 8.0.13. Mostly dependency updates (johnzon, dbcp2, myfaces,
> > > hsqldb,
> > > tomcat, jakarta faces), and some minor bugs (windows, jdk17+
> > > related
> > > backports), see below.
> > > 
> > > We might need to go through the 3rd party libs again and see, if
> > > there
> > > are additional updates we might want to include.
> > > 
> > > Would be worth to do a release soon (Mid/End of October?), imho.
> > > 
> > > Is there anything else we should include / patch before doing a
> > > 8.0.13?
> > > Any objections?
> > > 
> > > Wdyt?
> > > 
> > > Gruß
> > > Richard
> > > 
> > > 
> > > == Dependency upgrade
> > > 
> > > [.compact]
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-3985[TOMEE-3985]
> > BatchEE 1.0.2
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-3800[TOMEE-3800]
> > DBCP 2.9.0
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-3986[TOMEE-3986]
> > Hibernate Integration 5.6.9.Final
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4042[TOMEE-4042]
> > Jackson 2.13.4
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4020[TOMEE-4020]
> > Jakarta Faces 2.3.18
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4026[TOMEE-4026]
> > Johnzon 1.2.19
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4030[TOMEE-4030]
> > Log4J2 2.18.0
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-3998[TOMEE-3998]
> > MyFaces 2.3.10
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4044[TOMEE-4044]
> > Snakeyaml 1.32
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4002[TOMEE-4002]
> > Tomcat 9.0.64
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4051[TOMEE-4051]
> > Tomcat 9.0.65
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4018[TOMEE-4018]
> > bcprov-jdk15on 1.70
> > > == Bug
> > > 
> > > [.compact]
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4021[TOMEE-4021]
> > Unexpected ehcache 3.8.1 in tomee/lib
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4014[TOMEE-4014]
> > Unable to see TomEE version in Tomcat home page with Java 17
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4019[TOMEE-4019]
> > HSQLDB 2.7.0
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-3979[TOMEE-3979]
> > service.bat issue when using JRE_HOME on Windows
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4041[TOMEE-4041] 4
> > CVE Vulnerabilities in snakeyaml-1.30.jar
> > >  - link:
> > > https://issues.apache.org/jira/browse/TOMEE-4001[TOMEE-4001]
> > CVE-2022-34305 displaying user provided data without filtering,
> > exposing a
> > XSS vulnerability
> > >

Re: MP JWT TCK passing & HTTP Key URLs (was Re: Discuss changes to MP JWT support / JWTAuthConfiguration / Key resolution)

[Zowalla, Richard]

Thanks David for the work!

The CI looks good (compared to main): 
https://ci-builds.apache.org/job/Tomee/job/TOMEE-4050/

Gruß
Richard

Am Montag, dem 03.10.2022 um 21:47 +0200 schrieb Jean-Louis Monteiro:
> That sounds great.
> Good feature in addition to the bean validation support for claims.
> 
> Thanks David for the hard work on this.
> 
> Only missing part is OpenTracaing as far as I know.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Mon, Oct 3, 2022 at 6:58 PM David Blevins  >
> wrote:
> 
> > Hey All,
> > 
> > Provided we can get a good CI build on this PR, we're done with MP
> > JWT and
> > have some new functionality I'm pretty proud of and had a great
> > time
> > working on.
> > 
> >  - https://github.com/apache/tomee/pull/926
> > 
> > The new functionality in a nutshell is the ability to dynamically
> > resolve
> > and rotate JWT validation keys at runtime.  It is enabled by
> > default for
> > HTTP key locations, but can be enabled for any key location.
> > 
> > There's a full set of itests that verify our error handling and
> > logging
> > for all the various failure/recovery scenarios I could think
> > of.  Here's a
> > good example:
> > 
> >  -
> > https://github.com/apache/tomee/blob/TOMEE-4050/itests/microprofile-jwt-itests/src/test/java/org/apache/tomee/microprofile/jwt/itest/keys/http/HttpKeyRotationHttp500Test.java
> > 
> > I also wrote up a doc for MP JWT and our custom config properties:
> > 
> >  -
> > https://github.com/apache/tomee/blob/TOMEE-4050/docs/microprofile/jwt.adoc
> > 
> > If you have a fleet of servers, don't want to hardcode the keys in
> > the app
> > and need requests to work reliably even when errors occur in key
> > rotation,
> > this is your feature.
> > 
> > 
> > -David
> > 
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: [GitHub] [tomee v9] pull request #928: Dependency properties cleanup

[Zowalla, Richard]

It seems the issue arises from the cxf upgrade from 3.5.0 -> 3.5.3

I have reverted this specific upgrade on main and created 
https://issues.apache.org/jira/browse/TOMEE-4055 so we have the
exception in case have some more time to invest in updating this core
dependency. 

CI builds (main, TOMEE-4053) are triggered.

Gruß
Richard



Am Donnerstag, dem 29.09.2022 um 11:53 + schrieb Zowalla, Richard:
> We have some results from two runs, which are close in terms of
> failed
> test + they look similar to the ones on master ;-)
> 
> Looks like our last dependency update killed a few hundred tests.
> 
> Gruß
> Richard
> 
> Am Mittwoch, dem 28.09.2022 um 20:31 +0200 schrieb Swell:
> > Thanks for the CI job Richard !
> > 
> > while it builds i'll clean some props on my own branch using David
> > suggestions :
> > 
> > removing api, tck, and impl prefixes and have separate props for
> > microprofile api and smallrye impl
> > 
> > --
> > Swell
> > 
> > On Wed, 28 Sept 2022 at 20:21, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > > Regarding CI:
> > > 
> > > I just pushed Swell's branch as a branch named TOMEE-4053 to the
> > > TomEE
> > > main repo and we will get some CI results via
> > > https://ci-builds.apache.org/job/Tomee/job/TOMEE-4053/ soon (6-
> > > 8h)
> > > ;-)
> > > 
> > > I have no hard opinion regarding version.foo vs
> > > version.groupid.foo
> > > as
> > > long as we are consistent and every one is fine with the
> > > convention
> > > chosen.
> > > 
> > > Gruß
> > > Richard
> > > 
> > > 
> > > 
> > > Am Mittwoch, dem 28.09.2022 um 12:50 -0500 schrieb David Blevins:
> > > > Thanks for the proposal and the email!
> > > > 
> > > > I think it's fantastic to get the version strings normalized to
> > > > `version.foo`. We started with `foo.version` and gradually
> > > > changed to
> > > > `version.foo` as that kind of thing became more favored by
> > > > Maven
> > > > in
> > > > general, but we never went back and fixed the old properties so
> > > > we
> > > > have a mix.  Great to see that addressed.  The big PR is fine
> > > > for
> > > > me
> > > > -- let's get a CI build as Richard suggests.
> > > > 
> > > > In terms of the format, are we open to keeping it a simple
> > > > `version.foo` versus adding various prefixes before the `foo`
> > > > part
> > > > such as `tomee`, `api` or the groupId?  I'll never remember
> > > > which
> > > > prefix rule goes where and when, so I'll constantly be looking
> > > > it
> > > > up
> > > > and also further (unintentionally) adding to the inconsistency.
> > > > 
> > > > Intellij does have completion for Maven properties. Being able
> > > > to
> > > > type `version.` and then get a flat list of all the names would
> > > > be
> > > > fantastic.
> > > > 
> > > > Thoughts?
> > > > 
> > > > 
> > > > -David
> > > > 
> > > > 
> > > > > On Sep 28, 2022, at 9:25 AM, Swell 
> > > > > wrote:
> > > > > 
> > > > > Hi everyone,
> > > > > 
> > > > > The pom.xml of the project uses several properties to
> > > > > configure
> > > > > dependencies. some of which not used anymore since switching
> > > > > from
> > > > > geronimo
> > > > > to smallrye.
> > > > > 
> > > > > i've been working on removing orphan properties, renaming
> > > > > versions
> > > > > props on
> > > > > the same format whenever i was able. reorganizing a bit.
> > > > > 
> > > > > the proposed PR became a little big bang with almost 100 poms
> > > > > impacted, and
> > > > > hard to review.
> > > > > 
> > > > > the possible course of action would be collecting opinion
> > > > > here
> > > > > by
> > > > > mail
> > > > > before merging, see if it breaks and possibly fix afterward.
> > > > > 
> > > > > Thanks for your time.
> > > > > --
> > > > > Swell


smime.p7s
Description: S/MIME cryptographic signature

Re: [GitHub] [tomee v9] pull request #928: Dependency properties cleanup

[Zowalla, Richard]

We have some results from two runs, which are close in terms of failed
test + they look similar to the ones on master ;-)

Looks like our last dependency update killed a few hundred tests.

Gruß
Richard

Am Mittwoch, dem 28.09.2022 um 20:31 +0200 schrieb Swell:
> Thanks for the CI job Richard !
> 
> while it builds i'll clean some props on my own branch using David
> suggestions :
> 
> removing api, tck, and impl prefixes and have separate props for
> microprofile api and smallrye impl
> 
> --
> Swell
> 
> On Wed, 28 Sept 2022 at 20:21, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Regarding CI:
> > 
> > I just pushed Swell's branch as a branch named TOMEE-4053 to the
> > TomEE
> > main repo and we will get some CI results via
> > https://ci-builds.apache.org/job/Tomee/job/TOMEE-4053/ soon (6-8h)
> > ;-)
> > 
> > I have no hard opinion regarding version.foo vs version.groupid.foo
> > as
> > long as we are consistent and every one is fine with the convention
> > chosen.
> > 
> > Gruß
> > Richard
> > 
> > 
> > 
> > Am Mittwoch, dem 28.09.2022 um 12:50 -0500 schrieb David Blevins:
> > > Thanks for the proposal and the email!
> > > 
> > > I think it's fantastic to get the version strings normalized to
> > > `version.foo`. We started with `foo.version` and gradually
> > > changed to
> > > `version.foo` as that kind of thing became more favored by Maven
> > > in
> > > general, but we never went back and fixed the old properties so
> > > we
> > > have a mix.  Great to see that addressed.  The big PR is fine for
> > > me
> > > -- let's get a CI build as Richard suggests.
> > > 
> > > In terms of the format, are we open to keeping it a simple
> > > `version.foo` versus adding various prefixes before the `foo`
> > > part
> > > such as `tomee`, `api` or the groupId?  I'll never remember which
> > > prefix rule goes where and when, so I'll constantly be looking it
> > > up
> > > and also further (unintentionally) adding to the inconsistency.
> > > 
> > > Intellij does have completion for Maven properties. Being able to
> > > type `version.` and then get a flat list of all the names would
> > > be
> > > fantastic.
> > > 
> > > Thoughts?
> > > 
> > > 
> > > -David
> > > 
> > > 
> > > > On Sep 28, 2022, at 9:25 AM, Swell 
> > > > wrote:
> > > > 
> > > > Hi everyone,
> > > > 
> > > > The pom.xml of the project uses several properties to configure
> > > > dependencies. some of which not used anymore since switching
> > > > from
> > > > geronimo
> > > > to smallrye.
> > > > 
> > > > i've been working on removing orphan properties, renaming
> > > > versions
> > > > props on
> > > > the same format whenever i was able. reorganizing a bit.
> > > > 
> > > > the proposed PR became a little big bang with almost 100 poms
> > > > impacted, and
> > > > hard to review.
> > > > 
> > > > the possible course of action would be collecting opinion here
> > > > by
> > > > mail
> > > > before merging, see if it breaks and possibly fix afterward.
> > > > 
> > > > Thanks for your time.
> > > > --
> > > > Swell


smime.p7s
Description: S/MIME cryptographic signature

Re: [GitHub] [tomee v9] pull request #928: Dependency properties cleanup

[Zowalla, Richard]

Regarding CI:

I just pushed Swell's branch as a branch named TOMEE-4053 to the TomEE
main repo and we will get some CI results via
https://ci-builds.apache.org/job/Tomee/job/TOMEE-4053/ soon (6-8h) ;-)

I have no hard opinion regarding version.foo vs version.groupid.foo as
long as we are consistent and every one is fine with the convention
chosen.

Gruß
Richard



Am Mittwoch, dem 28.09.2022 um 12:50 -0500 schrieb David Blevins:
> Thanks for the proposal and the email! 
> 
> I think it's fantastic to get the version strings normalized to
> `version.foo`. We started with `foo.version` and gradually changed to
> `version.foo` as that kind of thing became more favored by Maven in
> general, but we never went back and fixed the old properties so we
> have a mix.  Great to see that addressed.  The big PR is fine for me
> -- let's get a CI build as Richard suggests.
> 
> In terms of the format, are we open to keeping it a simple
> `version.foo` versus adding various prefixes before the `foo` part
> such as `tomee`, `api` or the groupId?  I'll never remember which
> prefix rule goes where and when, so I'll constantly be looking it up
> and also further (unintentionally) adding to the inconsistency.
> 
> Intellij does have completion for Maven properties. Being able to
> type `version.` and then get a flat list of all the names would be
> fantastic.
> 
> Thoughts?
> 
> 
> -David
> 
> 
> > On Sep 28, 2022, at 9:25 AM, Swell 
> > wrote:
> > 
> > Hi everyone,
> > 
> > The pom.xml of the project uses several properties to configure
> > dependencies. some of which not used anymore since switching from
> > geronimo
> > to smallrye.
> > 
> > i've been working on removing orphan properties, renaming versions
> > props on
> > the same format whenever i was able. reorganizing a bit.
> > 
> > the proposed PR became a little big bang with almost 100 poms
> > impacted, and
> > hard to review.
> > 
> > the possible course of action would be collecting opinion here by
> > mail
> > before merging, see if it breaks and possibly fix afterward.
> > 
> > Thanks for your time.
> > --
> > Swell
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [GitHub] [tomee v9] pull request #928: Dependency properties cleanup

[Zowalla, Richard]

Hi,

yeah, such PRs are difficult to review by nature :)

Thanks for the effort to make it consistent and more clear!
Personally, I am fine with the proposal. 

If we don't want to do the "big bang integration" approach, we can
easily setup a CI job on jenkins (similar to our full build by simply
cloning it) and compare the results with current master.

The only thing we would need to do is to get the branch from Swell's
fork and push it to a branch on the TomEE repo. Would take only a
couple of minutes + 6-8 hours ci cycle time.

Wdyt?

Gruß
Richard


Am Mittwoch, dem 28.09.2022 um 16:25 +0200 schrieb Swell:
> Hi everyone,
> 
> The pom.xml of the project uses several properties to configure
> dependencies. some of which not used anymore since switching from
> geronimo
> to smallrye.
> 
> i've been working on removing orphan properties, renaming versions
> props on
> the same format whenever i was able. reorganizing a bit.
> 
> the proposed PR became a little big bang with almost 100 poms
> impacted, and
> hard to review.
> 
> the possible course of action would be collecting opinion here by
> mail
> before merging, see if it breaks and possibly fix afterward.
> 
> Thanks for your time.
> --
> Swell



smime.p7s
Description: S/MIME cryptographic signature

Re: Logging, uff-da

[Zowalla, Richard]

I think, that we are an app server first and not a logging framework
(;-)), so I am fine with 

"I have no idea what all that code does and I'm happy when I don't have to look 
at it".

However, I agree with JL, that we are really close to passing the TCK again, 
which would allow to cut a sweet & nice 9.0.0 Final before moving on to EE10 
work :)

Gruß
Richard


Am Sonntag, dem 25.09.2022 um 11:19 +0200 schrieb Jean-Louis Monteiro:
> The code is way too complex. I agree.
> 
> Abstraction is fine especially in Tomcat with the logging system and
> the
> class loading management to load configuration. If we want to be
> Tomcat we
> need to be able to support the same logging system in my opinion.
> 
> Now it can probably be done using either an existing abstraction like
> slf4j
> or log back or whatever. Or have something really simple.
> 
> TomEE 10 is a good target. We are too close to touch something like
> out
> logging system
> 
> Le ven. 23 sept. 2022, 23:01, David Blevins 
> a
> écrit :
> 
> > Not a problem for today, but I'm once again reminded how badly I
> > want to
> > toss out all of our logging abstraction.
> > 
> > Out Logger class started way back in 1999 before even Log4j
> > existed.  When
> > good-looking frameworks came into the picture, we kept using ours. 
> > That
> > bit is as our code for logging has grown in complexity and IMO has
> > grown
> > into something that's way too complicated and has bugs/issues
> > swimming
> > around in it.
> > 
> > One gripe is that since we added "async" logging, literally all log
> > statements appear to come from the same class and method
> > "org.apache.openejb.util.LogStreamAsync run".  For example:
> > 
> >   Sep 23, 2022 1:24:30 PM org.apache.openejb.util.LogStreamAsync
> > run
> >   SEVERE: Initialization attempt 1 failed. Supplier
> > org.apache.openejb.util.CachedSupplierTest$$Lambda$160/0x000800d3dc50@7f96b8b9
> > threw an exception.  Next retry will be in 1000 MILLISECONDS
> > 
> > Another is the plethora of bugs.  For example if you create a
> > Logger
> > instance like so:
> > 
> >  - Logger.getInstance(LogCategory.OPENEJB,
> > CachedSupplier.class.getSimpleName())
> > 
> > ...you will get an IndexOutOfBoundsException on each attempt to use
> > the
> > logger.  I found and fixed that, but the ironic part is that the
> > code with
> > the bug was trying to create a logging category and well... because
> > of the
> > "feature" above it's ignored anyway.
> > 
> > I don't think we want to dive into this in TomEE 9, but TomEE 10
> > would be
> > a good target.
> > 
> > I'm not sure why people are not screaming about our logging.
> > 
> > What's your opinion?
> > 
> >  - "All that code is great and we really need it"
> >  - "I have no idea what all that code does and I'm happy when I
> > don't have
> > to look at it"
> > 
> > 
> > -David
> > 
> > 



smime.p7s
Description: S/MIME cryptographic signature

Re: TomEE Jakarta and CXF

[Zowalla, Richard]

Hi JL,

really great news!

Thanks a lot.
Richard

Am Mittwoch, dem 21.09.2022 um 17:01 +0200 schrieb Jean-Louis Monteiro:
> Hi all,
> 
> After working quite hard moving TomEE to jakarta namespace (TomEE 9
> for EE
> 9.1), we started implementing MicroProfile 5.0 using SmallRye.
> 
> Looks like we are close to completion on MicroProfile, so I started
> looking
> back into the build in order to fix some remaining issues so that we
> can
> get a green build hopefully soon.
> 
> I also spent some time looking at the platform TCK.
> 
> So far, I've been able to fix remaining JSON-P, Servlet and JASPIC
> issues.
> We have a dozen of remaining failures.
> 
> *EJB Lite*
> com.sun.ts.tests.ejb30.lite.interceptor.singleton.lifecycle.annotated
> .Client#aroundConstructInterceptorTest_from_ejbembed
> 
> *JAX-RS*
> com.sun.ts.tests.jaxrs.api.rs.ext.interceptor.reader.readerintercepto
> rcontext.JAXRSClient#proceedThrowsWebApplicationExceptionTest_from_st
> andalone
> com.sun.ts.tests.jaxrs.ee.rs.core.responsebuilder.JAXRSClient
> entityObjectTest_from_standalone
> com.sun.ts.tests.jaxrs.ee.rs.ext.interceptor.containerreader.readerin
> terceptorcontext.JAXRSClient#proceedThrowsWebApplicationExceptionTest
> _from_standalone
> com.sun.ts.tests.jaxrs.spec.client.typedentities.JAXRSClient#clientAn
> yWriterUsageTest_from_standalone
> com.sun.ts.tests.jaxrs.spec.context.server.JAXRSClient#serverReaderIn
> jectionTest_from_standalone
> com.sun.ts.tests.jaxrs.spec.context.server.JAXRSClient#serverWriterIn
> jectionTest_from_standalone
> com.sun.ts.tests.jaxrs.spec.filter.interceptor.JAXRSClient#stringBean
> ReaderContainerInterceptorTest_from_standalone
> com.sun.ts.tests.jaxrs.spec.filter.interceptor.JAXRSClient#stringBean
> ReaderNoInterceptorTest_from_standalone
> com.sun.ts.tests.jaxrs.spec.filter.lastvalue.JAXRSClient#readerContex
> tOnContainerTest_from_standalone
> 
> *WebSockets*
> com.sun.ts.tests.websocket.ee.jakarta.websocket.session.WSClient#setT
> imeout1Test
> com.sun.ts.tests.websocket.spec.servercontainer.addendpoint.WSClien#s
> etTimeout1Test
> 
> 
> The 2 WebSocket issues don't seem to be a big thing. Based on this
> page
> https://cwiki.apache.org/confluence/display/TOMCAT/WebSocket+2.0+TCK Tomcat
> is 100% compliant and it says we need to tune expiration checks more
> frequently (setting).
> 
> So I'm starting on JAX RS tonight and tomorrow. Hopefully I can clear
> those
> up by end of this week.
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com



smime.p7s
Description: S/MIME cryptographic signature

Cut a 8.0.13?

[Zowalla, Richard]

Hi all,

our last 8.x release was in June and we have 22 pending updates/issues
for 8.0.13. Mostly dependency updates (johnzon, dbcp2, myfaces, hsqldb,
tomcat, jakarta faces), and some minor bugs (windows, jdk17+ related
backports), see below. 

We might need to go through the 3rd party libs again and see, if there
are additional updates we might want to include.

Would be worth to do a release soon (Mid/End of October?), imho.

Is there anything else we should include / patch before doing a 8.0.13?
Any objections?

Wdyt?

Gruß
Richard


== Dependency upgrade

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-3985[TOMEE-3985] BatchEE 
1.0.2
 - link:https://issues.apache.org/jira/browse/TOMEE-3800[TOMEE-3800] DBCP 2.9.0
 - link:https://issues.apache.org/jira/browse/TOMEE-3986[TOMEE-3986] Hibernate 
Integration 5.6.9.Final
 - link:https://issues.apache.org/jira/browse/TOMEE-4042[TOMEE-4042] Jackson 
2.13.4
 - link:https://issues.apache.org/jira/browse/TOMEE-4020[TOMEE-4020] Jakarta 
Faces 2.3.18
 - link:https://issues.apache.org/jira/browse/TOMEE-4026[TOMEE-4026] Johnzon 
1.2.19
 - link:https://issues.apache.org/jira/browse/TOMEE-4030[TOMEE-4030] Log4J2 
2.18.0
 - link:https://issues.apache.org/jira/browse/TOMEE-3998[TOMEE-3998] MyFaces 
2.3.10
 - link:https://issues.apache.org/jira/browse/TOMEE-4044[TOMEE-4044] Snakeyaml 
1.32
 - link:https://issues.apache.org/jira/browse/TOMEE-4002[TOMEE-4002] Tomcat 
9.0.64
 - link:https://issues.apache.org/jira/browse/TOMEE-4051[TOMEE-4051] Tomcat 
9.0.65
 - link:https://issues.apache.org/jira/browse/TOMEE-4018[TOMEE-4018] 
bcprov-jdk15on 1.70

== Bug

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-4021[TOMEE-4021] Unexpected 
ehcache 3.8.1 in tomee/lib
 - link:https://issues.apache.org/jira/browse/TOMEE-4014[TOMEE-4014] Unable to 
see TomEE version in Tomcat home page with Java 17
 - link:https://issues.apache.org/jira/browse/TOMEE-4019[TOMEE-4019] HSQLDB 
2.7.0
 - link:https://issues.apache.org/jira/browse/TOMEE-3979[TOMEE-3979] 
service.bat issue when using JRE_HOME on Windows 
 - link:https://issues.apache.org/jira/browse/TOMEE-4041[TOMEE-4041] 4 CVE 
Vulnerabilities in snakeyaml-1.30.jar 
 - link:https://issues.apache.org/jira/browse/TOMEE-4001[TOMEE-4001] 
CVE-2022-34305 displaying user provided data without filtering, exposing a XSS 
vulnerability

== Improvement

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-4000[TOMEE-4000] Add 
security.txt to website
 - link:https://issues.apache.org/jira/browse/TOMEE-3878[TOMEE-3878] Backport 
TOMEE-3877 to TomEE 8.x
 - link:https://issues.apache.org/jira/browse/TOMEE-3914[TOMEE-3914] Spring 3 
Dependencies in TomEE Root POM

== Task

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-4022[TOMEE-4022] Move to 
Apache Rat

== Fixed Common Vulnerabilities and Exposures (CVEs)

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-4041[TOMEE-4041] 4 CVE 
Vulnerabilities in snakeyaml-1.30.jar 
 - link:https://issues.apache.org/jira/browse/TOMEE-4001[TOMEE-4001] 
CVE-2022-34305 displaying user provided data without filtering, exposing a XSS 
vulnerability


smime.p7s
Description: S/MIME cryptographic signature

AW: [DISCUSS] Renaming of master branches to main?

[Zowalla, Richard]

Sure.

I created a related Jira: TOMEE-4025

In addition, I already asked INFRA, if this is a self service thing or if they 
need a ticket to switch the "default" branch for the GitHub/GitBox sync things.

Gruß
Richard

Von: Jean-Louis Monteiro 
Gesendet: Dienstag, 9. August 2022 15:24:50
An: dev@tomee.apache.org
Betreff: Re: [DISCUSS] Renaming of master branches to main?

I think you can take the action and update all tools. If you need some
help, lemme know
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Wed, Aug 3, 2022 at 6:40 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> +1
>
> On Thu, Jul 28, 2022 at 4:54 PM Richard Zowalla  wrote:
>
> > Hi all,
> >
> > I would like to get the community's opinion on renaming the "master"
> > branches for the TomEE related repositories to "main".
> >
> > I see quite a few ASF projects (and other OSS projects) have made the
> > change and I personally think we should, too, for the same reason of
> > promoting inclusivity (see [1]).
> >
> > I think we would need to update the target branch of the outstanding
> > PRs, update GitHub actions, update the Jenkins build config + local
> > checkouts. Anything else?
> >
> > Thoughts?
> >
> > Gruß
> > Richard
> >
> >
> > [1] https://sfconservancy.org/news/2020/jun/23/gitbranchname/
> >
> >
>

Re: Maintain 7.1.x branch (was [CANCEL] [VOTE] Apache TomEE 7.1.5)

[Zowalla, Richard]

e final release of the
> > > > > 7.1.x
> > > > > series. Subsequently, we announce the EOL of the 7.1.x
> > > > > similar to
> > > > > option (A).
> > > > > 
> > > > > ## Option (D)
> > > > > 
> > > > > We don’t release a new version of the 7.1.x series and do not
> > announce
> > > > > any sort of EOL statement (status quo). We agree to not put
> > > > > much
> > effort
> > > > > into the 7.1.x series and stop maintaining it.
> > > > > 
> > > > > ## Option (E)
> > > > > 
> > > > > We don’t release a new version of the 7.1.x series and do not
> > announce
> > > > > any sort of EOL statement (status quo). We agree to not put
> > > > > much
> > effort
> > > > > into the 7.1.x series and stop maintaining it. To avoid user
> > confusion,
> > > > > we remove the download links, the documentation and the
> > > > > artifacts
> > from
> > > > > the cdn but all 7.1.x release will always be available from
> > > > > the
> > > > > archive.
> > > > > 
> > > > > ## Option (F) – (Z)
> > > > > 
> > > > > » Your Input Here «
> > > > > 
> > > > > 
> > > > > 
> > > > > Perhaps there are other options as well, but that are the
> > > > > ones, which
> > > > > directly went into my mind while thinking about it. A similar
> > > > > discussion needs to be done for 1.7.x and 7.0.x if we find
> > > > > some
> > > > > consensus for the 7.1.x series.
> > > > > 
> > > > > I am a bit torn apart in this discussion. On the one hand, I
> > > > > am
> > > > > thinking: “Hey, we somehow “owe” the community one last
> > > > > release
> > before
> > > > > declaring it eol and stop maintaining it”. On the other hand,
> > > > > this
> > > > > rational could also be used as an excuse to ask for a “last”
> > > > > 7.0.x
> > or a
> > > > > “last” 1.7.x.
> > > > > 
> > > > > I agree, that releasing a TomEE 7.1.5 with known CXF
> > > > > vulnerabilities
> > > > > isn’t really desirable and we cannot maintain 3rd party libs
> > > > > indefinitely. We might be better in investing resources in
> > > > > 8.0.x and
> > a
> > > > > stable 9.0.x release in order to later shift our attention to
> > > > > EE10 ;)
> > > > > 
> > > > > Gruß
> > > > > Richard
> > > > > 
> > > > > 
> > > > > 
> > > > > [1] https://tomcat.apache.org/tomcat-80-eol.html
> > > > > 
> > > > > 
> > > > > Am Dienstag, dem 02.08.2022 um 16:07 +0200 schrieb Jean-Louis
> > Monteiro:
> > > > > > Hi all,
> > > > > > 
> > > > > > Don't want to hijack the other thread, so starting a new
> > > > > > one based
> > on
> > > > > > the
> > > > > > discussion.
> > > > > > 
> > > > > > I don't think releasing a "last 7.1.x" version with CVEs
> > > > > > would be
> > of
> > > > > > > any good
> > > > > > 
> > > > > > I join Alex on this one. Does it really make sense to
> > > > > > release a
> > TomEE
> > > > > > app
> > > > > > server with known CVEs?
> > > > > > 
> > > > > > I'm not arguing on the grype output and the validity or not
> > > > > > of the
> > > > > > report.
> > > > > > But overall, we do have EOL libraries in there and we know
> > > > > > we won't
> > > > > > get
> > > > > > patches even for CVEs for CXF and other libraries.
> > > > > > 
> > > > > > > @Alex Thanks. We might not be able to address all CVEs as
> > > > > > > some of
> > > > > > > the
> > > > > > libs used for EE7 aren't patched / updated anymore. I will
> > > > > > have a
> > > > > > look.
> > > > > > 
> > > > > > This is 

[CANCEL] [VOTE] Apache TomEE 7.1.5

[Zowalla, Richard]

Hi,

thanks for the concerns raised. Better to check the CVE report and do a re-roll 
;-)

@JL: Will take a look.

@Alex Thanks. We might not be able to address all CVEs as some of the libs used 
for EE7 aren't patched / updated anymore. I will have a look.

Gruß
Richard

Von: Jean-Louis Monteiro 
Gesendet: Dienstag, 2. August 2022 15:30:31
An: dev@tomee.apache.org
Betreff: Re: [VOTE] Apache TomEE 7.1.5

-1 (binding)

Something went bad during the release. Looks like our libs are still
1.7.5-SNAPSHOT.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Tue, Aug 2, 2022 at 2:37 PM Alex The Rocker  wrote:

> Hello,
>
> [-1] (non binding)
>
> Indeed, I downloaded TomEE+ 7.1.5 binary (from
>
> https://dist.apache.org/repos/dist/dev/tomee/staging-1206/tomee-7.1.5/apache-tomee-7.1.5-plus.tar.gz
> )
> and then I ran Grype (https://github.com/anchore/grype) on TomEE+'s
> archive extract directory.
>
> That gives 2 Critical and 125 High CVEs (see attached Grype output for
> this scan).
>
> I agree with whoever will say that Grype isn't quite smart, but
> nevertheless the world is now paranoid with security matter.
>
> I don't think releasing a "last 7.1.x" version with CVEs would be of
> any good, so Grype's output is all false positive, then at least we
> need a statement to avoid confusion in this page:
> https://tomee.apache.org/security/tomee.html
>
> Please also note in attached Grype output the Warning lines related to
> archive-xbean-asm6-shaded-4.8.jar: isn't that showing a somehow
> malformed MANIFEST ?
>
> Thanks,
> Alex
>
> Le lun. 1 août 2022 à 19:35, Richard Zowalla  a écrit :
> >
> > Hi all,
> >
> > this is a first attempt at a vote for a release of Apache TomEE 7.1.5
> >
> > It is a maintenance release with some bug fixes and dependencies
> > upgrades for which were was some interest on the list.
> >
> > Yet, a discussion, if this will be the last release of the 7.1.x
> > series, is pending.
> >
> > Here are some infos:
> >
> > Maven Repo:
> > https://repository.apache.org/content/repositories/orgapachetomee-1206
> >
> >   
> > 
> >   tomee-7.1.5-release-test
> >   Testing TomEE 7.1.5 release candidate
> > 
> > https://repository.apache.org/content/repositories/orgapachetomee-1206
> > 
> > 
> >   
> >
> >
> > Binaries & Source:
> > https://dist.apache.org/repos/dist/dev/tomee/staging-1206/
> >
> > Tag:
> > https://github.com/apache/tomee/tree/tomee-project-7.1.5
> >
> > Latest (green) CI/CD build:
> >
> > https://ci-builds.apache.org/job/Tomee/job/tomee-7.1.x/19/
> >
> > Release notes:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12349482
> >
> >
> > Here is an adoc generated version of the changelog as well:
> >
> >
> > == Dependency upgrade
> >
> > [.compact]
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2959[TOMEE-959]2  j
> > ackson 2.12.0
> >  - link:https://issues.apache.org/jira/browse/TOMEE-3941[TOMEE-3941]
> > ActiveMQ 5.16.5
> >  - link:https://issues.apache.org/jira/browse/TOMEE-3985[TOMEE-3985]
> > BatchEE 1.0.2
> >  - link:https://issues.apache.org/jira/browse/TOMEE-3772[TOMEE-3772]
> > JUnit 4.13.2
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2979[TOMEE-2979]
> > MyFaces 2.2.14
> >  - link:https://issues.apache.org/jira/browse/TOMEE-4016[TOMEE-4016]
> > Myfaces 2.2.15
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2958[TOMEE-2958]
> > Tomcat 8.5.61
> >  - link:https://issues.apache.org/jira/browse/TOMEE-4017[TOMEE-4017]
> > Tomcat 8.5.81
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2939[TOMEE-2939]
> > bcprov-jdk15on 1.67
> >  - link:https://issues.apache.org/jira/browse/TOMEE-4018[TOMEE-4018]
> > bcprov-jdk15on 1.70
> >  - link:https://issues.apache.org/jira/browse/TOMEE-3719[TOMEE-3719]
> > commons-io 2.8
> >
> > == Bug
> >
> > [.compact]
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2919[TOMEE-2919]
> > java.util.ConcurrentModificationException error deploying ear in TomEE
> Plus 7.1.4
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2968[TOMEE-2968]
> > Postgres connection error when a password contains "}"
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2125[TOMEE-2125]
> > Datasource config: MaxWait, timeBetweenEvictionRunsMillis and
> MinEvictableIdleTimeMillis are ignored
> >  - link:https://issues.apache.org/jira/browse/TOMEE-3718[TOMEE-3718]
> > Missing mime mappings
> >
> > == Improvement
> >
> > [.compact]
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2957[TOMEE-2957]
> > Fix OWASP Checks on ASF Jenkins Environment
> >  - link:https://issues.apache.org/jira/browse/TOMEE-2973[TOMEE-2973]
> > TomEE :: Examples :: JSF2/CDI/BV/JPA/DeltaSpike uses too old version of
> commons-lang3
> >
> >
> > Please VOTE
> >
> > [+1] go ship it
> > [+0] meh, don't care
> > [-1] stop, there is a ${showstopper}
> >
> > The VOTE is open for 72h or as long as needed.
> >
> > Gruß
> > Richard
> >
>

[DISCUSS] TomEE 7.1.x Release ?

[Zowalla, Richard]

Hi,

we had a discussion regarding a release of TomEE 7.1.x in April 22 [1].
After the discussion I fixed the CI build and updated some dependencies
mentioned in the discussion.

The (current) changelog looks like:

Bug
[TOMEE-2125] - Datasource config: MaxWait,
timeBetweenEvictionRunsMillis and MinEvictableIdleTimeMillis are
ignored
[TOMEE-2919] - java.util.ConcurrentModificationException error
deploying ear in TomEE Plus 7.1.4
[TOMEE-2968] - Postgres connection error when a password contains "}"
[TOMEE-3718] - Missing mime mappings

Improvement
[TOMEE-2957] - Fix OWASP Checks on ASF Jenkins Environment
[TOMEE-2973] - TomEE :: Examples :: JSF2/CDI/BV/JPA/DeltaSpike uses too
old version of commons-lang3

Dependency upgrade
[TOMEE-2939] - Update bcprov-jdk15on to 1.67
[TOMEE-2958] - Update to Tomcat 8.5.61
[TOMEE-2959] - Update to jackson 2.12.0
[TOMEE-2979] - Upgrade to MyFaces 2.2.14
[TOMEE-3719] - Upgrade to commons-io to 2.8
[TOMEE-3772] - Update JUnit to 4.13.2
[TOMEE-3941] - Apache ActiveMQ 5.16.5
[TOMEE-3985] - Upgrade BatchEE to 1.0.2
[TOMEE-4016] - Myfaces 2.2.15
[TOMEE-4017] - Tomcat 8.5.81
[TOMEE-4018] - Update bcprov-jdk15on to 1.70

The full build [2] for 7.1.x is green atm. So the question to discuss
would be: Do we want to do a release?

Side note: This could be an opportunity to "officially" announce 7.1.5
as the "last" release (eoling the 7.1.x series) + place a info box on
the download pages for 1.7.x, 7.0.x and 7.1.x.

Maintaining 8.x, 9.x (and other branches) might drain to much resources
and interest in providing patches / dependency updates for 7.1.x or
7.0.x was generally low in the last year(s).

What do you think?

Gruß
Richard

[1] https://lists.apache.org/thread/sz0kfocgd6248l2vxxgv3wjc5snh79q6
[2] https://ci-builds.apache.org/job/Tomee/job/tomee-7.1.x/




smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache TomEE 9.0.0-M8

[Zowalla, Richard]

Thanks Jon!

Both should be fixed now :)

Am Montag, dem 04.07.2022 um 13:13 +0200 schrieb Jean-Louis Monteiro:
> Thanks Jon,
> 
> Created 2 issues (TOMEE-4007 and TOMEE-4008) under
> https://issues.apache.org/jira/browse/TOMEE-3862
> 
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Mon, Jul 4, 2022 at 12:46 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
> > +1
> > 
> > Couple of notes:
> > 
> > * woodstox-core appears to have gone _back_ some versions (6.2.4 ->
> > 5.2.1)
> > * something is pulling in ASM as opposed to using the xbean-asm9-
> > shaded
> > 
> > I don't think either of these should block the release, but we
> > ought to
> > have a look as development moves forward.
> > 
> > Thanks for rolling the release!
> > 
> > Jon
> > 
> > On Tue, Jun 28, 2022 at 11:01 PM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> > 
> > > Hi,
> > > 
> > > As discussed, here is the vote for Apache TomEE 9.0.0-M8. This
> > > milestone
> > > differs from previous 9.x in the sense that we migrated all TomEE
> > > code to
> > > the new jakarta namespace. Previously, we used bytecode
> > > relocation but
> > most
> > > of the integration was broken (tests, arquillian, etc).
> > > 
> > > We are still working on some regressions and fixes in order to
> > > pass all
> > TCK
> > > for Jakarta EE 9.1. But starting to gather feedback can only help
> > > sooner
> > > rather than later.
> > > 
> > > This is a maintenance release with minor fixes and dependencies
> > > upgrades.
> > > 
> > > Maven staging repo
> > > https://repository.apache.org/content/repositories/orgapachetomee-1205/
> > > 
> > > Binaries and sources
> > > https://dist.apache.org/repos/dist/dev/tomee/tomee-9.0.0-M8
> > > 
> > > Github Tag
> > > https://github.com/apache/tomee/tree/tomee-project-9.0.0-M8
> > > 
> > > Commit hash
> > > 12e5dd91fe34affa775a68d5341576b417530008
> > > 
> > > Release Notes
> > > https://issues.apache.org/jira/projects/TOMEE/versions/12350178
> > > 
> > > Sub-task
> > > 
> > >- [TOMEE-3861 <
> > > https://issues.apache.org/jira/browse/TOMEE-3861>;] -
> > >Upgrade to apache-parent-26
> > >- [TOMEE-3865 <
> > > https://issues.apache.org/jira/browse/TOMEE-3865>;] -
> > >Switch arquillian to the new Servlet 5 protocol
> > >- [TOMEE-3866 <
> > > https://issues.apache.org/jira/browse/TOMEE-3866>;] -
> > >Upgrade Hibernate to 5.6.7 / Hibernate Validator to 7.0.2
> > > (Jakarta
> > > Artifact)
> > >- [TOMEE-3868 <
> > > https://issues.apache.org/jira/browse/TOMEE-3868>;] -
> > >Remove SAAJ Axis 1 provider
> > >- [TOMEE-3869 <
> > > https://issues.apache.org/jira/browse/TOMEE-3869>;] -
> > >Remove JAX-RPC
> > >- [TOMEE-3870 <
> > > https://issues.apache.org/jira/browse/TOMEE-3870>;] -
> > >Remove Management J2EE
> > >- [TOMEE-3877 <
> > > https://issues.apache.org/jira/browse/TOMEE-3877>;] -
> > No
> > >interface view EJB proxies broken on JDK16+
> > >- [TOMEE-3879 <
> > > https://issues.apache.org/jira/browse/TOMEE-3879>;] -
> > Add
> > >missing --add-opens options to itests/failover
> > >- [TOMEE-3881 <
> > > https://issues.apache.org/jira/browse/TOMEE-3881>;] -
> > Add
> > >JDK --add-opens to our scripts in openejb-standalone
> > >- [TOMEE-3920 <
> > > https://issues.apache.org/jira/browse/TOMEE-3920>;] -
> > Fix
> > >TomEE :: Web Examples :: Moviefun Rest
> > >- [TOMEE-3922 <
> > > https://issues.apache.org/jira/browse/TOMEE-3922>;] -
> > >Patch Tomcat JasperInitializer and create jira
> > >- [TOMEE-3925 <
> > > https://issues.apache.org/jira/browse/TOMEE-3925>;] -
> > Fix
> > >Websocket TLS Basic Auth
> > >- [TOMEE-3926 <
> > > https://issues.apache.org/jira/browse/TOMEE-3926>;] -
> > Fix
> > >Webservice SSL Client Certificate Example
> > >- [TOMEE-3930 <
> > > https://issues.apache.org/jira/browse/TOMEE-3930>;] -
> > fix
> > >arquillian-tomee-moviefun-example
> > >- [TOMEE-3931 <
> > > https://issues.apache.org/jira/browse/TOMEE-3931>;] -
> > fix
> > >example/cucumber-jvm
> > >- [TOMEE-3932 <
> > > https://issues.apache.org/jira/browse/TOMEE-3932>;] -
> > >Migration tips and tricks
> > >- [TOMEE-3939 <
> > > https://issues.apache.org/jira/browse/TOMEE-3939>;] -
> > Fix
> > >Jakarta Mail API with Apache Velocity Templating
> > >- [TOMEE-3940 <
> > > https://issues.apache.org/jira/browse/TOMEE-3940>;] -
> > Fix
> > >TomEE :: Examples :: JakartaMail API
> > >- [TOMEE-3943 <
> > > https://issues.apache.org/jira/browse/TOMEE-3943>;] -
> > Fix
> > >TomEE :: Examples :: Multiple JPA providers
> > >- [TOMEE-3944 <
> > > https://issues.apache.org/jira/browse/TOMEE-3944>;] -
> > Fix
> > >TomEE :: Examples :: Simple EAR :: Functional Tests
> > >- [TOMEE-3953 <
> > > https://issues.apache.org/jira/browse/TOMEE-3953>;] -
> > Fix
> > >TomEE :: Examples :: JPA with EclipseLink
> > >- 

Re: Apache TomEE 9.0.0-M8 release coming soon

[Zowalla, Richard]

Hi JL,

sounds good :) - +1

Gruß
Richard

Am Freitag, dem 24.06.2022 um 11:57 +0200 schrieb Jean-Louis Monteiro:
> Hi,
> 
> We have now completed all releases on libraries (specs for
> activation,
> mail, mail provider, BatchEE, OWB, BVal, Johnzon, etc). So we should
> be
> able to release it soon.
> 
> If you have fixes, you can push now, and I'll do the release later
> tonight
> for the weekend.
> 
> Then we can move on with fixing the remaining TCK failures, but at
> least
> everyone can start using it and provide feedback.
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache TomEE 8.0.12

[Zowalla, Richard]

Hi,

I can confirm, that the ZIP files are corrupted:

https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.12/apache-tomee-8.0.12-microprofile.zip

https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.12/apache-tomee-8.0.12-plume.zip

https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.12/apache-tomee-8.0.12-plus.zip

https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.12/apache-tomee-8.0.12-webprofile.zip

as they are only a few bytes in size.

Just checked the build and the zips are generated with correct sizes.
Might be a SVN commit / upload issue, i.e. should be an easy fix :)

Gruß
Richard

Am Freitag, dem 10.06.2022 um 15:44 +0200 schrieb Alex The Rocker:
> Hello,
> 
> Test are currently on-going on my side, will update soon.
> But it looks like
> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.12/apache-tomee-8.0.12-plus.zip
> is corrupted (the .tar.gz version is fine)
> => can the .zip be fixed ?
> 
> Kind regards,
> Alex
> 
> Le mar. 7 juin 2022 à 14:43, Jean-Louis Monteiro
>  a écrit :
> > Hi,
> > 
> > As discussed, here is the vote for Apache TomEE 8.0.12.
> > 
> > This is a maintenance release with minor fixes and dependencies
> > upgrades.
> > 
> > Maven staging repo
> > https://repository.apache.org/content/repositories/orgapachetomee-1203
> > 
> > Binaries and sources
> > https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.12/
> > 
> > Github Tag
> > https://github.com/apache/tomee/tree/tomee-project-8.0.12
> > 
> > Release Notes
> > https://issues.apache.org/jira/projects/TOMEE/versions/12351588
> > 
> > Sub-task
> > 
> >- [TOMEE-3647 
> > ;] -
> >Update example 'mvc-resteasy' to use Server/API Bom
> >- [TOMEE-3861 
> > ;] -
> >Upgrade to apache-parent-26
> > 
> > Bug
> > 
> >- [TOMEE-3849 
> > ;] -
> >EclipseLink JPA provider not discoverable in TomEE Plume
> > libraries
> >- [TOMEE-3903 
> > ;] -
> >Investigate *.tar.gz distributions aren't installed correctly to
> > Maven
> >Repository
> >- [TOMEE-3908 
> > ;] - CI
> >Job für TomEE Site Publish is failing
> >- [TOMEE-3919 
> > ;] - Fix
> >GitHub Actions Bom Generation targeting wrong branch
> >- [TOMEE-3935 
> > ;] - BOM
> >Regeneration fails due to GitHub Actions permission issue
> >- [TOMEE-3969 
> > ;] -
> >javax.cache API not part of Jakarta EE 8
> > 
> > Improvement
> > 
> >- [TOMEE-3924 
> > ;] -
> >Disable @dependabot via .asf.yaml
> >- [TOMEE-3934 
> > ;] -
> >Upgrade to Johnzon 1.2.18
> > 
> > Task
> > 
> >- [TOMEE-3905 
> > ;] - Fix
> >Post release pom versioning for tomee-8.x branch
> > 
> > Dependency upgrade
> > 
> >- [TOMEE-3911 
> > ;] -
> >Upgrade XBean to 4.21
> >- [TOMEE-3912 
> > ;] -
> >Upgrade TomEE Patch Plugin to 0.9
> >- [TOMEE-3913 
> > ;] -
> >Examples: Upgrade JUnit 4.12 to 4.13.2
> >- [TOMEE-3918 
> > ;] -
> >Upgrade Johnzon to 1.2.17
> >- [TOMEE-3941 
> > ;] -
> >Apache ActiveMQ 5.16.5
> >- [TOMEE-3961 
> > ;] -
> >Upgrade to Apache Tomcat 9.0.63 (CVE-2022-29885)
> >- [TOMEE-3977 
> > ;] -
> >Apache OpenWebBeans 2.0.27
> > 
> > Documentation
> > 
> >- [TOMEE-3846 
> > ;] -
> >Inconsistence between tomee flavors comparison in website and
> > actual jars
> >- [TOMEE-3904 
> > ;] -
> >Enhance / Update existing release documentation
> > 
> > 
> > Please VOTE
> > 
> > [+1] go ship it
> > [+0] meh, don't care
> > [-1] stop, there is a ${showstopper}
> > 
> > The VOTE is open for 72h
> > 
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: Jakarta Mail TCK - Additional Thoughts? (was: TomEE 9.x - from javax to jakarta namespace)

[Zowalla, Richard]

Hi Romain,

thanks for the pointer - it sounds somehow familiar to what we
observed. Need to check though :)

Gruß
Richard

Am Donnerstag, dem 02.06.2022 um 09:17 +0200 schrieb Romain Manni-
Bucau:
> Hi,
> 
> Did you try handling LITERAL+ capability (1)? I don't think we do as
> of
> today.
> 
> (1)
> https://datatracker.ietf.org/doc/html/rfc7888#:~:text=LITERAL%2B%20allows%20the%20alternate%20form%20of%20literals%20(called%20%22non%2D,are%204096%20bytes%20or%20less
> .
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> 
> 
> Le mar. 31 mai 2022 à 09:54, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> 
> > Hi,
> > 
> > short update on this:
> > 
> > Collaborated with JL and exchanged some ideas via Slack.
> > 
> > We now tested James + Greenmail as mail servers to rule out any
> > hard-
> > coded TCK assumption regarding James. Both fail with the same
> > exception
> > / issue on the same TCK mail:
> > https://github.com/eclipse-ee4j/mail-tck/blob/2.0.0/tests/mailboxes/test1/9
> > 
> > The difference between the RI and our impl is basically the literal
> > header:
> > 
> > a5 APPEND test1 () "8-Dec-1996 15:30:12 +0100" {150432}
> > a5 BAD APPEND failed. Illegal arguments.
> > 
> > vs (RI):
> > 
> > A6 APPEND test1 () "08-Dec-1996 15:30:12 +0100" {153113+}
> > A6 OK [APPENDUID 466034631 1] APPEND completed.
> >   Copied 1 messages
> > 
> > I pushed a configured Jakarta Mail TCK 2.0.1 setup with updated
> > instructions into this repository: https://github.com/rzo1/mail-tck
> > 
> > In addition, I am CC'ing the geronimo list, in case some people
> > there
> > have additional ideas. Otherwise, we will need to take a dive into
> > the
> > imap spec / server-side impl to get any clues :)
> > 
> > Gruß
> > Richard
> > 
> > 
> > Am Dienstag, dem 24.05.2022 um 19:46 + schrieb Zowalla,
> > Richard:
> > > Hi,
> > > 
> > > I spend some more time on the mail tck and got some additional
> > > insights:
> > > 
> > > There is one specific mail from the TCK mailbox (test1, mail no.
> > > 9),
> > > which breaks the current Geronimo mail impl. This happens, if you
> > > try
> > > to bootstrap / setup the test mailbox before running the TCK
> > > according
> > > ti their documentation. The same procedere just works, if the
> > > reference
> > > impl is used.
> > > 
> > > The failing tests in the mail tck report similar issues regarding
> > > failed IMAP commands. Therefore, I assume, that the underlying
> > > issue
> > > is
> > > similar, i.e. if we solve that, we likely fix some of the TCK
> > > tests
> > > too.
> > > 
> > > I added some instructions to
> > > https://issues.apache.org/jira/browse/GERONIMO-6835 to reproduce
> > > the
> > > issue without actually running the TCK, so we might have the
> > > chance
> > > to
> > > debug it easily.
> > > 
> > > Basically:
> > > 
> > > - Checkout 
> > > https://github.com/rzo1/geronimo-javamail/tree/tck-issues
> > > - Follow the instructions in tck.adoc to start up a mail server
> > > (docker-compose + docker exec)
> > > - Run "fpopulate" with arguments "-s test1 -d
> > > imap://user01%40james.local:1234@localhost:1143 -D" from within
> > > your
> > > IDE
> > > - Observe the debug output on the console
> > > 
> > > 
> > > There is a difference between the message length between the RI
> > > and
> > > the
> > > Geronimo impl (as reported by the { } literal). This might be the
> > > cause
> > > (??), but I have no idea what is going on or why it is happening.
> > > 
> > > Maybe someone has an idea what is going on here? Or has a pointer
> > > where
> > > to look at? I might be "lost in the tck madness" for today :)
> > > 
> > > Gruß
> > > Richard
> > > 
> > > 
> > > 
> > > Am Dienstag, dem 24.05.2022 um 17:13 + sc

AW: Release TomEE 8.0.12

[Zowalla, Richard]

+1

Von: Jean-Louis Monteiro 
Gesendet: Freitag, 3. Juni 2022 08:49:23
An: dev@tomee.apache.org
Betreff: Release TomEE 8.0.12

Hi all,

We have a couple of requested fixes on the TomEE 8.x branch. Should we do a
release?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: Jakarta Mail TCK - Additional Thoughts? (was: TomEE 9.x - from javax to jakarta namespace)

[Zowalla, Richard]

Hi,

short update on this:

Collaborated with JL and exchanged some ideas via Slack.

We now tested James + Greenmail as mail servers to rule out any hard-
coded TCK assumption regarding James. Both fail with the same exception
/ issue on the same TCK mail: 
https://github.com/eclipse-ee4j/mail-tck/blob/2.0.0/tests/mailboxes/test1/9

The difference between the RI and our impl is basically the literal
header:

a5 APPEND test1 () "8-Dec-1996 15:30:12 +0100" {150432}
a5 BAD APPEND failed. Illegal arguments.

vs (RI):

A6 APPEND test1 () "08-Dec-1996 15:30:12 +0100" {153113+}
A6 OK [APPENDUID 466034631 1] APPEND completed.
  Copied 1 messages

I pushed a configured Jakarta Mail TCK 2.0.1 setup with updated
instructions into this repository: https://github.com/rzo1/mail-tck 

In addition, I am CC'ing the geronimo list, in case some people there
have additional ideas. Otherwise, we will need to take a dive into the
imap spec / server-side impl to get any clues :)

Gruß
Richard


Am Dienstag, dem 24.05.2022 um 19:46 +0000 schrieb Zowalla, Richard:
> Hi,
> 
> I spend some more time on the mail tck and got some additional
> insights:
> 
> There is one specific mail from the TCK mailbox (test1, mail no. 9),
> which breaks the current Geronimo mail impl. This happens, if you try
> to bootstrap / setup the test mailbox before running the TCK
> according
> ti their documentation. The same procedere just works, if the
> reference
> impl is used.
> 
> The failing tests in the mail tck report similar issues regarding
> failed IMAP commands. Therefore, I assume, that the underlying issue
> is
> similar, i.e. if we solve that, we likely fix some of the TCK tests
> too.
> 
> I added some instructions to 
> https://issues.apache.org/jira/browse/GERONIMO-6835 to reproduce the
> issue without actually running the TCK, so we might have the chance
> to
> debug it easily. 
> 
> Basically:
> 
> - Checkout https://github.com/rzo1/geronimo-javamail/tree/tck-issues
> - Follow the instructions in tck.adoc to start up a mail server
> (docker-compose + docker exec)
> - Run "fpopulate" with arguments "-s test1 -d
> imap://user01%40james.local:1234@localhost:1143 -D" from within your
> IDE
> - Observe the debug output on the console
> 
> 
> There is a difference between the message length between the RI and
> the
> Geronimo impl (as reported by the { } literal). This might be the
> cause
> (??), but I have no idea what is going on or why it is happening.
> 
> Maybe someone has an idea what is going on here? Or has a pointer
> where
> to look at? I might be "lost in the tck madness" for today :)
> 
> Gruß
> Richard
> 
> 
> 
> Am Dienstag, dem 24.05.2022 um 17:13 + schrieb Zowalla, Richard:
> > To give a more detailed view / update from the spec tck party
> > regarding
> > activation and mail:
> > 
> > (A) Geronimo Activation 2.0
> > 
> > After a first milestone (M1) and some additional fixes after
> > running
> > the activation TCK [1] and related signatures tests, we are now
> > passing
> > them. 
> > 
> > JL prepared a release artifact (1.0.0), which is currently under
> > vote.
> > 
> > During the tck work, we found some inconsistency / unspecified
> > behaviour of "normalizeMimeTypeParameter" of ActivationDataFlavor.
> > While this method is tested in the TCK on the basis of the
> > reference
> > implementation neither the spec itself nor the javadoc are really
> > clear
> > about the "right" return value. At the moment, we adjusted it to
> > pass
> > the TCK test in question.
> > 
> > There is an ongoing discussion at dev@geronimo if this is a desired
> > behaviour or if a system property should be introduced in order to
> > reduce the possibility of breaking some users.
> > 
> > (B) Geronimo Mail 2.0 / 2.1
> > 
> > The current mail impl has some TCK failures. It seems, that we need
> > to
> > do some additional work to get it compliant with the standalone
> > mail
> > tck [3].
> > 
> > The signature tests are failing for Java 11 but are fine with Java
> > 8
> > [4] due to some usage of Object#finalize() and missing annotations
> > (only available in Java 9+) in the Geronimo implementation. While
> > it
> > is
> > not that important for EE9, we need to keep it in mind for EE10.
> > 
> > We currently pass 166 out of 321 mail tck tests [5]. I guess, we
> > need
> > to give it some more love to get the numbers up and finally get it
> > to
> > pass the mail tck. The good thing is, that we already pass the
> >

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Guess it is:

jakarataee-api-9.1-M2-SNAPSHOT-tomcat.jar vs jakarataee-api-9.1-M1-
tomcat.jar

(similar to javaee-api differences in the gist)


Am Mittwoch, dem 25.05.2022 um 12:21 +0200 schrieb Jean-Louis Monteiro:
> Hey David,
> 
> Does not seem to be undoable.
> 
> Just a quick question: do you want the diff between jakartaee-api and
> javaee-api or do you want diff between every version of the
> jakartaee-api?
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Wed, May 25, 2022 at 2:44 AM David Blevins <
> david.blev...@gmail.com>
> wrote:
> 
> > I haven't had a chance to dig into the differences on the
> > jakartaee-api
> > jars like I did for the javaee-api jars.  Is it at all possible you
> > could
> > create a diff like this one?
> > 
> >  -
> > https://gist.github.com/dblevins/7535757fb8eceb51ed30ae9b705f9cbf/revisions
> > 
> > I basically built each, did a `jar tvf javaee-api-8.0-5.jar | cut
> > -c 37-`
> > and pasted that output into a gist, then did it again against the
> > javaee-api-8.0-6.jar and updated the content in the gist.
> > 
> > It'd be super helpful.
> > 
> > I did look at the commits, but with maven transitive deps and such
> > I don't
> > really trust myself to eyeball it correctly.
> > 
> > 
> > -David
> > 
> > 
> > > On May 24, 2022, at 6:44 AM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> > > Alright, time for a new update.
> > > 
> > > TomEE 8.x with JDK8 and EE8 is equivalent to TomEE 9.x with
> > > JDK11/JDK17
> > and
> > > EE9.
> > > The build is still not full green, but it's time to start
> > > grabbing user
> > > feedback as we discussed.
> > > 
> > > So the work started to take every single piece we fixed or
> > > patched to
> > start
> > > doing releases and if possible run TCK + signature Tests.
> > > 
> > > David did activation and mail milestones. Richard used the
> > > milestone to
> > fix
> > > and we are now under vote for activation 2.0 final and Richard is
> > > making
> > > some awesomeness on the mail spec and impl. We should be able to
> > > get
> > final
> > > versions soon.
> > > 
> > > We also have an OWB vote starting today for a jakarta compatible
> > > version
> > > (including TCK).
> > > Next step is to release a milestone for jakartaee-api 9.1-M2 and
> > > move on.
> > > 
> > > 
> > > 
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > > 
> > > 
> > > On Thu, May 12, 2022 at 9:29 AM Wiesner, Martin <
> > > martin.wies...@hs-heilbronn.de> wrote:
> > > 
> > > > +1
> > > > 
> > > > Best
> > > > Martin
> > > > —
> > > > https://twitter.com/mawiesne
> > > > 
> > > > 
> > > > Am 11.05.2022 um 19:00 schrieb Cesar Hernandez <
> > > > cesargu...@gmail.com
> > > > <mailto:cesargu...@gmail.com>>:
> > > > 
> > > > +1, Thank you!
> > > > 
> > > > 
> > > > El mié, 11 may 2022 a las 9:06, Daniel Dias Dos Santos (<
> > > > daniel.dias.analist...@gmail.com > daniel.dias.analist...@gmail.com>>)
> > > > escribió:
> > > > 
> > > > +1
> > > > 
> > > > On Wed, May 11, 2022, 12:00 Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de > > > richard.zowa...@hs-heilbronn.de
> > > > 
> > > > wrote:
> > > > 
> > > > I am fine with it: +1
> > > > 
> > > > Von: Jean-Louis Monteiro  > > > jlmonte...@tomitribe.com>>
> > > > Gesendet: Mittwoch, 11. Mai 2022 15:57:54
> > > > An: dev@tomee.apache.org<mailto:dev@tomee.apache.org>
> > > > Betreff: Re: TomEE 9.x - from javax to jakarta namespace
> > > > 
> > > > Alright, with the latest changes pushed yesterday and today, we
> > > > are now
> > > > at
> > > > the exact same numbers for TomEE 8.x / Jakarta EE 8 under JDK8
> > > > and TomEE
> > > > 9.x / Jakarta 9.1 under JDK17.
> > > > 
> > > > If everyone is ok with it, we can create a new

Re: How Can I Help ?

[Zowalla, Richard]

Hi,

sorry for the late response - been busy with some oss / normal work.

If you like to work on one of these areas, the first step would be to
clone the TomEE repository and try to build TomEE based on the
documentation provided in the repository.

Some examples already have a Jira [1] task, so if you find a task you
would like to work on, just sent an email with "TOMEE-" and someone
will assign it to you. The workflow is documented here: [2].

Gruß
Richard

[1] https://issues.apache.org/
[2] https://tomee.apache.org/community/contributing/workflow.html

Am Montag, dem 09.05.2022 um 20:15 -0600 schrieb AD:
> Hello Richard
> 
> From the areas of work that you mentioned in your email , I think I
> would
> be interested in 2 areas below-
> 
> 1. Other areas of work involve upgrading / revising our current
> examples
> (TomEE 8.x, TomEE 9.x) by using our "BOM" approach in order to make
> them easier to consume / understand so users do not have to think
> about: "Which version of XY do I need to include to make it work?!".
> Some of them are using very old libraries (9+ years old)  and would
> benefit from an upgrade to newer dependencies / versions or use
> deprecated jks keystore formats, which need conversion to drop
> warnings. Such activies are rather "easy" and can help to get a
> feeling
> for TomEE and OSS contributions in general.
> 
> 2. Of course our current website and the dev/admin/migration
> documentation
> would also benefit from a careful review and a subsequent review and
> revise.
> 
> Thank you
> -AD
> 
> On Mon, May 9, 2022 at 12:07 AM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Hi AD,
> > 
> > TomEE consumes a variety of ASF projects for specific parts of its
> > core
> > functionality.
> > 
> > Apache Geronimo provides JavaEE / JakartaEE libraries and
> > Microprofile
> > implementations [1]. A big effort would be to update the
> > Microprofile
> > implementation in Geronimo to support JakartaEE namespace (so we do
> > not
> > need to use SmallRye implementation like all the other app
> > servers).
> > There was some discussion in [2] about this topic.
> > 
> > Another examples are the dependencies currently shaded to bring
> > javax
> > -> jakarta namespace listed in [3]. Some efforts on other projects
> > (like the apache commons project) are needed in order to drop our
> > fork/shade and handle the namespace change in the related project.
> > Such
> > activities are also of great value to the TomEE community.
> > 
> > While working on the namespace change for ActiveMQ, the people over
> > there asked why we didn't support ActiveMQ Artemis yet [4]. We do
> > not
> > have integration code for Artemis, so this would also be a possible
> > area of contribution if you have the skills / experience in this
> > field.
> > 
> > Other areas of work involve upgrading / revising our current
> > examples
> > (TomEE 8.x, TomEE 9.x) by using our "BOM" approach in order to make
> > them easier to consume / understand so users do not have to think
> > about: "Which version of XY do I need to include to make it
> > work?!".
> > Some of them are using very old libraries (9+ years old)  and would
> > benefit from an upgrade to newer dependencies / versions or use
> > deprecated jks keystore formats, which need conversion to drop
> > warnings. Such activies are rather "easy" and can help to get a
> > feeling
> > for TomEE and OSS contributions in general.
> > 
> > Of course our current website and the dev/admin/migration
> > documentation
> > would also benefit from a careful review and a subsequent review
> > and
> > revise.
> > 
> > Some harder tasks involve running the TCK [5] and working on
> > plattform
> > compliance for EE9.1, i.e. fixing and working on the tests. Same is
> > true for working on the Smallrye miroprofile integration and fixing
> > tests / things. TCK tasks require some organisation / discussion
> > via
> > the list to avoid that work is conducted multiple times.
> > 
> > Perhaps, you suffer from a TomEE bug yourself and nobody did find
> > time
> > to work on it yet. That would also be a starting point to jump in.
> > 
> > As you probably see, there is always a lof of work to do. It fully
> > depends on your available time / resources. My list isn't nearly
> > complete but that is what I have directly in my mind.
> > 
> > Gruß
> > Richard
> > 
> > [1] https://geronimo.

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Am Mittwoch, dem 25.05.2022 um 02:28 +0200 schrieb Jean-Louis Monteiro:
> For 2/ I can help you tomorrow if you want/need.

Would be very much appreciated to get a second pair of eyes.

Gruß
Richard



smime.p7s
Description: S/MIME cryptographic signature

Jakarta Mail TCK - Additional Thoughts? (was: TomEE 9.x - from javax to jakarta namespace)

[Zowalla, Richard]

Hi,

I spend some more time on the mail tck and got some additional
insights:

There is one specific mail from the TCK mailbox (test1, mail no. 9),
which breaks the current Geronimo mail impl. This happens, if you try
to bootstrap / setup the test mailbox before running the TCK according
ti their documentation. The same procedere just works, if the reference
impl is used.

The failing tests in the mail tck report similar issues regarding
failed IMAP commands. Therefore, I assume, that the underlying issue is
similar, i.e. if we solve that, we likely fix some of the TCK tests
too.

I added some instructions to 
https://issues.apache.org/jira/browse/GERONIMO-6835 to reproduce the
issue without actually running the TCK, so we might have the chance to
debug it easily. 

Basically:

- Checkout https://github.com/rzo1/geronimo-javamail/tree/tck-issues
- Follow the instructions in tck.adoc to start up a mail server
(docker-compose + docker exec)
- Run "fpopulate" with arguments "-s test1 -d
imap://user01%40james.local:1234@localhost:1143 -D" from within your
IDE
- Observe the debug output on the console


There is a difference between the message length between the RI and the
Geronimo impl (as reported by the { } literal). This might be the cause
(??), but I have no idea what is going on or why it is happening.

Maybe someone has an idea what is going on here? Or has a pointer where
to look at? I might be "lost in the tck madness" for today :)

Gruß
Richard



Am Dienstag, dem 24.05.2022 um 17:13 + schrieb Zowalla, Richard:
> To give a more detailed view / update from the spec tck party
> regarding
> activation and mail:
> 
> (A) Geronimo Activation 2.0
> 
> After a first milestone (M1) and some additional fixes after running
> the activation TCK [1] and related signatures tests, we are now
> passing
> them. 
> 
> JL prepared a release artifact (1.0.0), which is currently under
> vote.
> 
> During the tck work, we found some inconsistency / unspecified
> behaviour of "normalizeMimeTypeParameter" of ActivationDataFlavor.
> While this method is tested in the TCK on the basis of the reference
> implementation neither the spec itself nor the javadoc are really
> clear
> about the "right" return value. At the moment, we adjusted it to pass
> the TCK test in question.
> 
> There is an ongoing discussion at dev@geronimo if this is a desired
> behaviour or if a system property should be introduced in order to
> reduce the possibility of breaking some users.
> 
> (B) Geronimo Mail 2.0 / 2.1
> 
> The current mail impl has some TCK failures. It seems, that we need
> to
> do some additional work to get it compliant with the standalone mail
> tck [3].
> 
> The signature tests are failing for Java 11 but are fine with Java 8
> [4] due to some usage of Object#finalize() and missing annotations
> (only available in Java 9+) in the Geronimo implementation. While it
> is
> not that important for EE9, we need to keep it in mind for EE10.
> 
> We currently pass 166 out of 321 mail tck tests [5]. I guess, we need
> to give it some more love to get the numbers up and finally get it to
> pass the mail tck. The good thing is, that we already pass the
> javamail
> tests for TomEE [6].
> 
> Gruß
> Richard
> 
> 
> 
> [1] https://jakarta.ee/specifications/activation/2.0/
> [2] https://lists.apache.org/thread/h8twm4rmdxt67fx227nyywjp96b6cky1
> [3] https://jakarta.ee/specifications/mail/2.0/
> [4] https://issues.apache.org/jira/browse/GERONIMO-6834
> [5] https://issues.apache.org/jira/browse/GERONIMO-6835
> [6]  
> https://tck.work/tomee/tests?build=1651841331620=com.sun.ts.tests.javamail
> 
> Am Dienstag, dem 24.05.2022 um 15:44 +0200 schrieb Jean-Louis
> Monteiro:
> > Alright, time for a new update.
> > 
> > TomEE 8.x with JDK8 and EE8 is equivalent to TomEE 9.x with
> > JDK11/JDK17 and
> > EE9.
> > The build is still not full green, but it's time to start grabbing
> > user
> > feedback as we discussed.
> > 
> > So the work started to take every single piece we fixed or patched
> > to
> > start
> > doing releases and if possible run TCK + signature Tests.
> > 
> > David did activation and mail milestones. Richard used the
> > milestone
> > to fix
> > and we are now under vote for activation 2.0 final and Richard is
> > making
> > some awesomeness on the mail spec and impl. We should be able to
> > get
> > final
> > versions soon.
> > 
> > We also have an OWB vote starting today for a jakarta compatible
> > version
> > (including TCK).
> > Next step is to release a milestone for jakartaee-api 9.1-M2 and
> > move
> &g

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

To give a more detailed view / update from the spec tck party regarding
activation and mail:

(A) Geronimo Activation 2.0

After a first milestone (M1) and some additional fixes after running
the activation TCK [1] and related signatures tests, we are now passing
them. 

JL prepared a release artifact (1.0.0), which is currently under vote.

During the tck work, we found some inconsistency / unspecified
behaviour of "normalizeMimeTypeParameter" of ActivationDataFlavor.
While this method is tested in the TCK on the basis of the reference
implementation neither the spec itself nor the javadoc are really clear
about the "right" return value. At the moment, we adjusted it to pass
the TCK test in question.

There is an ongoing discussion at dev@geronimo if this is a desired
behaviour or if a system property should be introduced in order to
reduce the possibility of breaking some users.

(B) Geronimo Mail 2.0 / 2.1

The current mail impl has some TCK failures. It seems, that we need to
do some additional work to get it compliant with the standalone mail
tck [3].

The signature tests are failing for Java 11 but are fine with Java 8
[4] due to some usage of Object#finalize() and missing annotations
(only available in Java 9+) in the Geronimo implementation. While it is
not that important for EE9, we need to keep it in mind for EE10.

We currently pass 166 out of 321 mail tck tests [5]. I guess, we need
to give it some more love to get the numbers up and finally get it to
pass the mail tck. The good thing is, that we already pass the javamail
tests for TomEE [6].

Gruß
Richard



[1] https://jakarta.ee/specifications/activation/2.0/
[2] https://lists.apache.org/thread/h8twm4rmdxt67fx227nyywjp96b6cky1
[3] https://jakarta.ee/specifications/mail/2.0/
[4] https://issues.apache.org/jira/browse/GERONIMO-6834
[5] https://issues.apache.org/jira/browse/GERONIMO-6835
[6]  
https://tck.work/tomee/tests?build=1651841331620=com.sun.ts.tests.javamail

Am Dienstag, dem 24.05.2022 um 15:44 +0200 schrieb Jean-Louis Monteiro:
> Alright, time for a new update.
> 
> TomEE 8.x with JDK8 and EE8 is equivalent to TomEE 9.x with
> JDK11/JDK17 and
> EE9.
> The build is still not full green, but it's time to start grabbing
> user
> feedback as we discussed.
> 
> So the work started to take every single piece we fixed or patched to
> start
> doing releases and if possible run TCK + signature Tests.
> 
> David did activation and mail milestones. Richard used the milestone
> to fix
> and we are now under vote for activation 2.0 final and Richard is
> making
> some awesomeness on the mail spec and impl. We should be able to get
> final
> versions soon.
> 
> We also have an OWB vote starting today for a jakarta compatible
> version
> (including TCK).
> Next step is to release a milestone for jakartaee-api 9.1-M2 and move
> on.
> 
> 
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Thu, May 12, 2022 at 9:29 AM Wiesner, Martin <
> martin.wies...@hs-heilbronn.de> wrote:
> 
> > +1
> > 
> > Best
> > Martin
> > —
> > https://twitter.com/mawiesne
> > 
> > 
> > Am 11.05.2022 um 19:00 schrieb Cesar Hernandez <
> > cesargu...@gmail.com
> > <mailto:cesargu...@gmail.com>>:
> > 
> > +1, Thank you!
> > 
> > 
> > El mié, 11 may 2022 a las 9:06, Daniel Dias Dos Santos (<
> > daniel.dias.analist...@gmail.com > daniel.dias.analist...@gmail.com>>)
> > escribió:
> > 
> > +1
> > 
> > On Wed, May 11, 2022, 12:00 Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de > richard.zowa...@hs-heilbronn.de>>
> > wrote:
> > 
> > I am fine with it: +1
> > 
> > Von: Jean-Louis Monteiro  > jlmonte...@tomitribe.com>>
> > Gesendet: Mittwoch, 11. Mai 2022 15:57:54
> > An: dev@tomee.apache.org<mailto:dev@tomee.apache.org>
> > Betreff: Re: TomEE 9.x - from javax to jakarta namespace
> > 
> > Alright, with the latest changes pushed yesterday and today, we are
> > now
> > at
> > the exact same numbers for TomEE 8.x / Jakarta EE 8 under JDK8 and
> > TomEE
> > 9.x / Jakarta 9.1 under JDK17.
> > 
> > If everyone is ok with it, we can create a new milestone and give
> > users
> > the
> > opportunity to provide us with some feedback and to report bugs.
> > 
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> > 
> > 
> > On Tue, May 10, 2022 at 7:06 PM David Blevins <
> > david.blev...@gmail.com>
> > wrote:
> > 
> > Was checking 

Re: [VOTE] Apache TomEE javaee-api-8.0-6

[Zowalla, Richard]

+1

Am Montag, dem 23.05.2022 um 10:02 +0200 schrieb Jean-Louis Monteiro:
> Hi folks!
> 
> I'd like to call a VOTE on Apache TomEE javaee-api-8.0.6.
> 
> This mostly contains 2 fixes to remove non EE APIs such as
> javax.cache and
> more important javax.xml because it's messing up with JDK11 compiler
> (conflict with a java.xml module).
> 
> https://issues.apache.org/jira/browse/TOMEE-3969
> https://issues.apache.org/jira/browse/TOMEE-3970
> 
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomee-1202
> 
> The source zip can be found at
> https://dist.apache.org/repos/dist/dev/tomee/javaee-api-8.0-6/
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache TomEE javaee-api-8.0-6

[Zowalla, Richard]

Hi Alex,

afaik, the difference is as follows:

The JAR "javaee-api-XY.jar" contains all required APIs for a given EE
release. 

Tomcat - by design - also includes some EE APIs. To avoid duplicates
with the APIs brought in by Tomcat, there is "javaee-api-XY-
tomcat.jar", which excludes those already provided APIs (via Tomcat)
from the shaded JAR.

I admit, that the naming with the classifier "tomcat" is a bit
misleading / confusing.

Hope it helps
Gruß
Richard

Am Montag, dem 23.05.2022 um 10:57 +0200 schrieb Alex The Rocker:
> Hello Jean-Louis & Richard,
> 
> Maybe the issue is that Apache TomEE+ 8.0.11 contains
> javaee-api-8.0-5-tomcat.jar instead of javaee-api-8.05.jar ?
> (I am referring to the ZIP distribution of Apache TomEE+ 8.0.11,
> found
> at : 
> https://www.apache.org/dyn/closer.cgi/tomee/tomee-8.0.11/apache-tomee-8.0.11-plus.zip
> )
> 
> Also it's unclear to me why there is a javaee-api-8.0-6-tomcat.jar
> and
> a javaee-api-8.0-6.jar : what's the difference between these two
> JARs,
> and why Apache TomEE+ seems to "prefer" to embed
> javaee-api-*-tomcat.jar ?
> 
> Kind regards,
> Alex
> 
> Le lun. 23 mai 2022 à 10:42, Jean-Louis Monteiro
>  a écrit :
> > Hi Alex,
> > 
> > Thanks for checking and testing.
> > 
> > I'm sorry I can't understand the issue.
> > I double checked the size from the 8.0-5
> > https://repository.apache.org/content/repositories/releases/org/apache/tomee/javaee-api/8.0-5/
> > 
> > And the staging repo for 8.0-6
> > https://repository.apache.org/content/repositories/orgapachetomee-1202/org/apache/tomee/javaee-api/8.0-6/
> > 
> > Both the tomcat and the non-tomcat version are smaller in 8.0-6
> > 
> > 
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> > 
> > 
> > On Mon, May 23, 2022 at 10:35 AM Alex The Rocker <
> > alex.m3...@gmail.com>
> > wrote:
> > 
> > > Hi Jean-Louis,
> > > 
> > > I have tested, and JDK11 build issue which I had with
> > > javaee-api-8.0-5-tomcat.jar as not reproducible so the issue is
> > > fixed
> > > from my perspective
> > > 
> > > However, one detail worries me:
> > >javaee-api-8.0-5-tomcat.jar size is 1040753 bytes large
> > >javaee-api-8.0-6.jar size is 1437502 bytes large
> > > 
> > > Since javaee-api 8.0.6's goal is to remove package which are
> > > duplicate
> > > of ones available in Java standard libraries, how can we have
> > > almost
> > > 400kbytes more from 8.0.5 to 8.0.6 ?
> > > 
> > > Also why in TomEE 8.0.11 the JAR name is javaee-api-8.0-5-
> > > tomcat.jar
> > > and now we have a javaee-api-8.0-6.jar (I personally prefer that
> > > later
> > > naming) ?
> > > 
> > > Kind regards,
> > > Alexandre
> > > 
> > > Le lun. 23 mai 2022 à 10:03, Jean-Louis Monteiro
> > >  a écrit :
> > > > Hi folks!
> > > > 
> > > > I'd like to call a VOTE on Apache TomEE javaee-api-8.0.6.
> > > > 
> > > > This mostly contains 2 fixes to remove non EE APIs such as
> > > > javax.cache
> > > and
> > > > more important javax.xml because it's messing up with JDK11
> > > > compiler
> > > > (conflict with a java.xml module).
> > > > 
> > > > https://issues.apache.org/jira/browse/TOMEE-3969
> > > > https://issues.apache.org/jira/browse/TOMEE-3970
> > > > 
> > > > The staging repo is:
> > > > https://repository.apache.org/content/repositories/orgapachetomee-1202
> > > > 
> > > > The source zip can be found at
> > > > https://dist.apache.org/repos/dist/dev/tomee/javaee-api-8.0-6/
> > > > 
> > > > Please VOTE
> > > > 
> > > > [+1] go ship it
> > > > [+0] meh, don't care
> > > > [-1] stop, there is a ${showstopper}
> > > > 
> > > > The VOTE is open for 72h
> > > > 
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache TomEE javaee-api-8.0-6

[Zowalla, Richard]

Hi,

isn't it:

javaee-api-8.0-6-tomcat.jar Mon May 23 07:51:38 UTC 2022966046

See: 
https://repository.apache.org/content/repositories/orgapachetomee-1202/org/apache/tomee/javaee-api/8.0-6/

Or: 

https://repository.apache.org/content/repositories/orgapachetomee-1202/org/apache/tomee/javaee-api/8.0-6/javaee-api-8.0-6-tomcat.jar

which is smaller? 1040753 vs 966046?

Gruß
Richard


Am Montag, dem 23.05.2022 um 10:35 +0200 schrieb Alex The Rocker:
> Hi Jean-Louis,
> 
> I have tested, and JDK11 build issue which I had with
> javaee-api-8.0-5-tomcat.jar as not reproducible so the issue is fixed
> from my perspective
> 
> However, one detail worries me:
>javaee-api-8.0-5-tomcat.jar size is 1040753 bytes large
>javaee-api-8.0-6.jar size is 1437502 bytes large
> 
> Since javaee-api 8.0.6's goal is to remove package which are
> duplicate
> of ones available in Java standard libraries, how can we have almost
> 400kbytes more from 8.0.5 to 8.0.6 ?
> 
> Also why in TomEE 8.0.11 the JAR name is javaee-api-8.0-5-tomcat.jar
> and now we have a javaee-api-8.0-6.jar (I personally prefer that
> later
> naming) ?
> 
> Kind regards,
> Alexandre
> 
> Le lun. 23 mai 2022 à 10:03, Jean-Louis Monteiro
>  a écrit :
> > Hi folks!
> > 
> > I'd like to call a VOTE on Apache TomEE javaee-api-8.0.6.
> > 
> > This mostly contains 2 fixes to remove non EE APIs such as
> > javax.cache and
> > more important javax.xml because it's messing up with JDK11
> > compiler
> > (conflict with a java.xml module).
> > 
> > https://issues.apache.org/jira/browse/TOMEE-3969
> > https://issues.apache.org/jira/browse/TOMEE-3970
> > 
> > The staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomee-1202
> > 
> > The source zip can be found at
> > https://dist.apache.org/repos/dist/dev/tomee/javaee-api-8.0-6/
> > 
> > Please VOTE
> > 
> > [+1] go ship it
> > [+0] meh, don't care
> > [-1] stop, there is a ${showstopper}
> > 
> > The VOTE is open for 72h
> > 
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars

[Zowalla, Richard]

Yes. Examples + Arquillian Tests + TCKs 

Most of the embedded TCKs + arquillian adaptors did not run due to a
build timeout after 12h (as CDI TCK never completed due to missing
javax.cache classes).

Am Montag, dem 23.05.2022 um 09:45 +0200 schrieb Jean-Louis Monteiro:
> Yes examples, but the main build itself is green.
> I'll get the examples fixed and start the javaee-api release in
> parallel.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Mon, May 23, 2022 at 8:25 AM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > The TomEE 8.x full build has some test failures due to missing
> > deps,
> > but that was to expect:
> > https://ci-builds.apache.org/job/Tomee/job/tomee-8.x-build-full/72/
> > 
> > Mostly missing API classes (javax.cache) :)
> > 
> > Am Sonntag, dem 22.05.2022 um 20:39 +0200 schrieb Jean-Louis
> > Monteiro:
> > > I have done it and made sure the build was still green. Sent a
> > > new
> > > email to
> > > see if there are objections to release it and then TomEE 8.x
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > > 
> > > 
> > > On Fri, May 20, 2022 at 7:35 AM Zowalla, Richard <
> > > richard.zowa...@hs-heilbronn.de> wrote:
> > > 
> > > > I see no issues.
> > > > 
> > > > We would need to add a clear list of APIs, which will be
> > > > removed
> > > > and
> > > > document them in an Jira. We can then reference it in any
> > > > potential
> > > > release note, to indicate, that were was a change which might
> > > > impact
> > > > consumers.
> > > > 
> > > > Gruß
> > > > Richard
> > > > 
> > > > 
> > > > Am Dienstag, dem 17.05.2022 um 13:21 -0700 schrieb David
> > > > Blevins:
> > > > > > On May 17, 2022, at 8:17 AM, Jean-Louis Monteiro <
> > > > > > jlmonte...@tomitribe.com> wrote:
> > > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > We do have an uber jar with all Java/Jakarta EE APIs. It
> > > > > > makes
> > > > > > it
> > > > > > easier
> > > > > > for a user to use the server and requires less dependencies
> > > > > > in
> > > > > > our
> > > > > > modules.
> > > > > > 
> > > > > > Though it's convenient, it looks like we are embedding too
> > > > > > many
> > > > > > APIs in it,
> > > > > > and non EE APIs, for instance javax.xml.namespace. And
> > > > > > since
> > > > > > Java
> > > > > > Modules
> > > > > > it does generate compilation issues with Eclipse at least
> > > > > > but
> > > > > > also
> > > > > > javac.
> > > > > > 
> > > > > > Another option is to require the users to add a module-
> > > > > > info.java
> > > > > > with their
> > > > > > explicit requirements so there is no conflict in the
> > > > > > javax.xml.namespace
> > > > > > package.
> > > > > > 
> > > > > > Any issue to remove all non EE APIs from our Uber jar?
> > > > > 
> > > > > No issues from me.  Though it might be helpful if there was a
> > > > > to-
> > > > > be-
> > > > > removed list we could take a look at as I know we keep
> > > > > removing
> > > > > things from Jakarta with the idea that vendors can still
> > > > > implement
> > > > > them and ship them, but they're just not officially part of
> > > > > the
> > > > > platform anymore.
> > > > > 
> > > > > For example the Embedded EJB Container is one of them that's
> > > > > been
> > > > > removed.
> > > > > 
> > > > > 
> > > > > 
> > > > > -David
> > > > > 
> > > > > 
> > > > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars

[Zowalla, Richard]

The TomEE 8.x full build has some test failures due to missing deps,
but that was to expect: 
https://ci-builds.apache.org/job/Tomee/job/tomee-8.x-build-full/72/

Mostly missing API classes (javax.cache) :)

Am Sonntag, dem 22.05.2022 um 20:39 +0200 schrieb Jean-Louis Monteiro:
> I have done it and made sure the build was still green. Sent a new
> email to
> see if there are objections to release it and then TomEE 8.x
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Fri, May 20, 2022 at 7:35 AM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > I see no issues.
> > 
> > We would need to add a clear list of APIs, which will be removed
> > and
> > document them in an Jira. We can then reference it in any potential
> > release note, to indicate, that were was a change which might
> > impact
> > consumers.
> > 
> > Gruß
> > Richard
> > 
> > 
> > Am Dienstag, dem 17.05.2022 um 13:21 -0700 schrieb David Blevins:
> > > > On May 17, 2022, at 8:17 AM, Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com> wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > We do have an uber jar with all Java/Jakarta EE APIs. It makes
> > > > it
> > > > easier
> > > > for a user to use the server and requires less dependencies in
> > > > our
> > > > modules.
> > > > 
> > > > Though it's convenient, it looks like we are embedding too many
> > > > APIs in it,
> > > > and non EE APIs, for instance javax.xml.namespace. And since
> > > > Java
> > > > Modules
> > > > it does generate compilation issues with Eclipse at least but
> > > > also
> > > > javac.
> > > > 
> > > > Another option is to require the users to add a module-
> > > > info.java
> > > > with their
> > > > explicit requirements so there is no conflict in the
> > > > javax.xml.namespace
> > > > package.
> > > > 
> > > > Any issue to remove all non EE APIs from our Uber jar?
> > > 
> > > No issues from me.  Though it might be helpful if there was a to-
> > > be-
> > > removed list we could take a look at as I know we keep removing
> > > things from Jakarta with the idea that vendors can still
> > > implement
> > > them and ship them, but they're just not officially part of the
> > > platform anymore.
> > > 
> > > For example the Embedded EJB Container is one of them that's been
> > > removed.
> > > 
> > > 
> > > 
> > > -David
> > > 
> > > 
> > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] Release train for APIs and TomEE 8.x

[Zowalla, Richard]

I am fine and have no objections. 

If you need help or some supporting hands, just give a ping.

Gruß
Richard

Am Sonntag, dem 22.05.2022 um 20:36 +0200 schrieb Jean-Louis Monteiro:
> Hi all,
> 
> I'm planning to start some releases.
> 
> First the javaee-api 8.0.x which essentially fixes some APIs that
> aren't
> part of EE 8 and which are messing up with Java Compiler after Java
> 11.
> 
> Then TomEE 8.x with the new API and a fewx fixes and dependencies
> upgrade.
> 
> And finally the jakartaee-api in a milestone version to start having
> more
> stable builds and see where we are.
> 
> Any objections?
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars

[Zowalla, Richard]

I see no issues.

We would need to add a clear list of APIs, which will be removed and
document them in an Jira. We can then reference it in any potential
release note, to indicate, that were was a change which might impact
consumers.

Gruß
Richard


Am Dienstag, dem 17.05.2022 um 13:21 -0700 schrieb David Blevins:
> > On May 17, 2022, at 8:17 AM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> > 
> > Hi all,
> > 
> > We do have an uber jar with all Java/Jakarta EE APIs. It makes it
> > easier
> > for a user to use the server and requires less dependencies in our
> > modules.
> > 
> > Though it's convenient, it looks like we are embedding too many
> > APIs in it,
> > and non EE APIs, for instance javax.xml.namespace. And since Java
> > Modules
> > it does generate compilation issues with Eclipse at least but also
> > javac.
> > 
> > Another option is to require the users to add a module-info.java
> > with their
> > explicit requirements so there is no conflict in the
> > javax.xml.namespace
> > package.
> > 
> > Any issue to remove all non EE APIs from our Uber jar?
> 
> No issues from me.  Though it might be helpful if there was a to-be-
> removed list we could take a look at as I know we keep removing
> things from Jakarta with the idea that vendors can still implement
> them and ship them, but they're just not officially part of the
> platform anymore.
> 
> For example the Embedded EJB Container is one of them that's been
> removed.
> 
> 
> 
> -David
> 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: TomEE 9.x - jakarta.enterpise.inject.spi.Extension VS javax.enterpise.inject.spi.Extension

[Zowalla, Richard]

Thanks for your view, David.

I created TOMEE-3968 to track this change/feature. 

Notice to the community: It might be a beginner friendly task to work
on if someone has some available cycles - as I debugged it for
Deltaspike my memory is quite fresh and I can give some pointers were
to look at ;)

Gruß
Richard

Am Freitag, dem 13.05.2022 um 21:45 -0700 schrieb David Blevins:
> > On May 12, 2022, at 12:02 AM, Richard Zowalla 
> > wrote:
> > 
> > - Additionally scan for "javax.enterprise.inject.spi.Extension"
> > - If we find something, log a warning/info that this is not really
> > expected (?) and load the extension instead of failing with an
> > unsatisfied dependency error later.
> 
> I'd support that.  More than likely those extensions will refer to
> javax.enterprise packages and fail, but that might be better than
> silently skipping them.  At least with an explicit failure you'd be
> aware of the issue and have a stacktrace.
> 
> 
> -David
> 


smime.p7s
Description: S/MIME cryptographic signature

AW: [GitHub] [tomee] rzo1 commented on a diff in pull request #883: Tomee 3824

[Zowalla, Richard]

Hi,

it's about the same Jira Issue, so it's fine to use this pull request.

Many thanks for your contribution!

Gruß
Richard

Von: Zoltán Tichov 
Gesendet: Samstag, 14. Mai 2022 21:16:03
An: dev@tomee.apache.org
Betreff: Re: [GitHub] [tomee] rzo1 commented on a diff in pull request #883: 
Tomee 3824

Hi!

I resolve the issue, do I need to make a new pull request?

Thanks: Zoltán

On Sat, May 14, 2022 at 7:31 PM GitBox  wrote:

>
> rzo1 commented on code in PR #883:
> URL: https://github.com/apache/tomee/pull/883#discussion_r873055259
>
>
> ##
>
> container/openejb-jee/src/main/java/org/apache/openejb/jee/ObjectFactory.java:
> ##
> @@ -166,4 +167,12 @@ public JAXBElement createConnector(final
> Webservices value) {
>  public JAXBElement createFacesConfig(final FacesConfig
> value) {
>  return new JAXBElement(_FacesConfig_QNAME,
> FacesConfig.class, null, value);
>  }
> +
> + /**
> + * Create an instance of {@link JAXBElement }{@code <}{@link
> WebFragment }{@code >}}
> + */
> +@XmlElementDecl(namespace = "http://java.sun.com/xml/ns/javaee;,
> name = "web-fragment")
>
> Review Comment:
>Thanks for the comment. I think, that the best way would be to follow
> up on the list. @dblevins might have some thoughts / insights here.
>
>Often the best way to get answers / details is to ask on the list. The
> cool thing is, that the list archive will have this information years later.
>
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>

Re: TOMEE-3824 New Jakarta EE 9 XML namespace not recognized in web-fragment.xml (was Re: How can I help?)

[Zowalla, Richard]

mespace.  I
> > > > know
> > we're
> > > > testing at least some those old namespaces and the new
> > > > namespace.  We
> > have
> > > > some test descriptors here:
> > > > 
> > > > -
> > > > 
> > https://github.com/apache/tomee/tree/master/container/openejb-jee/src/test/resources
> > > > I don't recall the name of those tests offhand, but if you
> > > > search for
> > the
> > > > names of some of those files that should get you close.
> > > > 
> > > > 
> > > > Now a couple thoughts as I see potential for some short-term
> > > > work and
> > some
> > > > longer-term work.
> > > > 
> > > > - Long-term: We're clearly still referring to "
> > > > http://java.sun.com/xml/ns/javaee; as the primary
> > > > namespace.  That's
> > not
> > > > going to age well.  If someone has to write an email like this
> > > > in 15
> > years,
> > > > they'll likely have to explain what "javaee" is like I had to
> > > > harken
> > back
> > > > to "J2EE".  We should probably make the new Jakarta EE
> > > > namespace be the
> > > > primary namespace and rework all the JAXB code and namespace
> > > > filters
> > > > accordingly.
> > > > 
> > > > - Short-term: Do not do any of that and avoid opening that can
> > > > of worms
> > > > at all cost.  Get the file to parse with the minimum change
> > > > possible.
> > Get
> > > > some experience with the code and a successful contribution in
> > > > the can.
> > > > 
> > > > This is what I'd do regardless of (or because of?) years of
> > experience.  I
> > > > always take the quick win before attempting the big one.
> > > > 
> > > > If you get into the code and decide the big change sounds like
> > > > fun, we
> > can
> > > > make a ticket for it and plan it.  Probably we'd want to shore
> > > > up any
> > test
> > > > coverage we'd be lacking and also get a full TCK run to see
> > > > what those
> > > > numbers look like so we can spot regressions.
> > > > 
> > > > Hope some of this is helpful!
> > > > 
> > > > Don't hesitate to be super noisy and ask lots and lots of
> > > > questions.
> > > > Silence is death. :)
> > > > 
> > > > 
> > > > -David
> > > > 
> > > > 
> > > > > On May 5, 2022, at 3:31 PM, Zoltán Tichov <
> > > > > zoltan.tic...@gmail.com>
> > > > wrote:
> > > > > Hi Richard!
> > > > > I found a ticket with a bug that I also encountered.The
> > > > > ticket is open
> > > > and
> > > > > unassigned.
> > > > > Should I try to fix it? If so, how can it be assigned to me?
> > > > > https://issues.apache.org/jira/browse/TOMEE-3824
> > > > > 
> > > > > Best: Zoltán
> > > > > 
> > > > > On Wed, Apr 27, 2022 at 8:36 AM Zowalla, Richard <
> > > > > richard.zowa...@hs-heilbronn.de> wrote:
> > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > it would certainly help to track these issues as an issue.
> > > > > > 
> > > > > > Maybe they are already solved (as the code has evolved) but
> > > > > > maybe not,
> > > > > > so it would be good to have them.
> > > > > > 
> > > > > > Gruß
> > > > > > Richard
> > > > > > 
> > > > > > Am Dienstag, dem 26.04.2022 um 21:54 +0200 schrieb Zoltán
> > > > > > Tichov:
> > > > > > > Hi Richard!
> > > > > > > 
> > > > > > > I have found two errors in Tomee 9.0.0-M7. Should I make
> > > > > > > tickets for
> > > > > > > these
> > > > > > > errors and try to fix them?
> > > > > > > Although they may have been fixed in the next version
> > > > > > > (9.0.0-M8)
> > > > > > > 
> > > > > > > Zoltán
> > > > > > > 
> > > > > > > On Sun, Apr 24, 2022 at 11:06 AM Zowalla, Richard <

AW: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

I am fine with it: +1

Von: Jean-Louis Monteiro 
Gesendet: Mittwoch, 11. Mai 2022 15:57:54
An: dev@tomee.apache.org
Betreff: Re: TomEE 9.x - from javax to jakarta namespace

Alright, with the latest changes pushed yesterday and today, we are now at
the exact same numbers for TomEE 8.x / Jakarta EE 8 under JDK8 and TomEE
9.x / Jakarta 9.1 under JDK17.

If everyone is ok with it, we can create a new milestone and give users the
opportunity to provide us with some feedback and to report bugs.

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


On Tue, May 10, 2022 at 7:06 PM David Blevins 
wrote:

> Was checking out the TCK numbers this morning can make to suggest a
> 9.0.0-M8 while things look good and found this amazing email.
>
> The 9.0.x branch is looking absolutely amazing!!!
>
> What do we think about pushing out a 9.0.0-M8 while things are in their
> peak-stable state?  I'm sure we'll have to rip up a few more things to
> finish off the remaining Jakarta EE and MP TCK issues.  Would be great to
> have something that isn't M7 to fallback on as a reference point to track
> regressions.
>
> Thoughts?
>
>
> -David
>
>
>
> > On May 10, 2022, at 3:56 AM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> >
> > Hi all,
> >
> > Time for some reporting
> >
> > On our journey to migrate TomEE over from javax to jakarta namespace, we
> > had many issues.
> > After updating all our code, we had to do a bunch of dependency upgrades
> > after upgrading many of them (OpenWebbeans, BVal, Geronimo, etc).
> >
> > We then faced many issues with non compatible libraries for example
> > (ActiveMQ, commons-dbcp, CXF, sxc, taglib, etc). So we ended up repacking
> > them in our own groupId after using the Maven Shade plugin to relocate
> the
> > packages.
> >
> > We worked on BVal TCK and CDI TCK and we are close to passing them.
> >
> > But we had before to solve all our outdated MicroProfile 1.3 stack to the
> > most recent and jakarta compatible version. Geronimo implementations
> being
> > far being, we decided to use some SmallRye implementations until we can
> > dedicate some time to update our Apache implementations (config, metrics,
> > health, openapi, opentracing, fault tolerance).
> >
> > Our build is now more stable, but still not green. Some issues are
> > basically easy to fix and most people could do it (examples for
> instance).
> >
> > https://ci-builds.apache.org/job/Tomee/job/master-build-full/
> >
> > The integration for openapi, opentracing and fault tolerance is not done
> > and we are far from passing the TCK. On config, metrics and health we are
> > close. Same for our JWT implementation.
> >
> > I also wanted to have a view on the platform TCK, so I decided to stop
> > TomEE work in order to spend time on the Platform TCK to do all
> dependency
> > upgrades and get the TCK to run properly. I'm pleased to announce that
> > after 2 weeks of hard work, we are 99% compatible
> >
> > https://tck.work/tomee/build?id=1652104572445
> >
> > Thanks everyone for the help.
> > Keep going and if you need some guidance or help, let us know.
> >
> > For coordination purposes, here is the issue
> > https://issues.apache.org/jira/browse/TOMEE-3862
> > Many subtasks are there and you can create new tasks when needed and ask
> > any committer to assign it to you.
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Thu, May 5, 2022 at 11:13 AM Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> >
> >> Yes - we already yanked it in 9.x
> >>
> >> Gruß
> >> Richard
> >>
> >> Am Donnerstag, dem 05.05.2022 um 10:10 +0100 schrieb Jonathan
> >> Gallimore:
> >>> Sounds good. I'll drop the transformer from the 8.x branch (looks
> >>> like we
> >>> don't use it in 9.x), and I'll create a single example to demonstrate
> >>> it in
> >>> a sandbox.
> >>>
> >>> Jon
> >>>
> >>> On Wed, May 4, 2022 at 12:32 PM Zowalla, Richard <
> >>> richard.zowa...@hs-heilbronn.de> wrote:
> >>>
> >>>> You are right - we can remove it imho from 8.x as we do not test
> >>>> with
> >>>> it and the transformed samples might not even work, e.g.
> >>>> dependencies
> >>>> are not migrated,

Re: How Can I Help with the Apache Microprofile implementation

[Zowalla, Richard]

Hi,

the ASF impls of the MP specifications are hosted by the Geronimo
project.

Yes - you are right. We would need to update every MP specification in
Geronimo and add / update the related implementation. That involves
finding the differences between each version, writing tests, etc.

In the end it is only a question of resources / time and priorities. If
we want to pursue this further, we would need to have some volunteers
jumping in and do the actual work over there. There was a great
discussion regarding this topic on the list in March.

For now, the main workload seems to target 9.0.0-M8 and to get our full
build + EE TCK back to the valley of green ;) - but if we would have
some more volunteers / contributors with time / resources an update of
ASF MP impls is not that far away...

Gruß
Richard

Am Dienstag, dem 10.05.2022 um 11:39 -0600 schrieb Memo Díaz Solis:
> Hi All, I've been reading the mailing list and noticed that it was
> decided
> to use smallRye in some cases. I would like to help with the Apache
> implementation and as far as I understand, those are outdated.


smime.p7s
Description: S/MIME cryptographic signature

Re: MicroProfile JWT 2.0 support

[Zowalla, Richard]

Hi,

you can find the MP TCK Harness (which is run in the TomEE build) here:

https://github.com/apache/tomee/tree/master/tck/microprofile-tck/jwt

The actual MP JWT TCK tsts are in this artifact

org.eclipse.microprofile.jwt
microprofile-jwt-auth-tck

the related repository of the MP JWT TCK source code can be found here:

https://github.com/eclipse/microprofile-jwt-auth

Gruß
Richard


Am Dienstag, dem 10.05.2022 um 19:58 -0600 schrieb Memo Díaz Solis:
> Helping on TOMEE-3948 in some way, sounds good to me .
> 
> I'll start by reviewing the Spec and then the TCK.
> 
> Regarding the Spec, I found this
> <
> https://download.eclipse.org/microprofile/microprofile-jwt-auth-2.0/microprofile-jwt-auth-spec-2.0.html
> >
> so
> I assume that's where the spec is published, but for the TCK I got
> this: Projects
> (tck.work)  which is for TomEE, but
> did
> not find the microprofile TCK  so I guess it is for Jakarta EE only.
> So for
> the Eclipse Microprofile is there a TCK built in a different
> workspace?
> 
> 
> El mar, 10 may 2022 a las 18:11, David Blevins (<
> david.blev...@gmail.com>)
> escribió:
> 
> > Hi Memo!
> > 
> > First, thanks for volunteering!  Thrilled to work on this with you.
> > 
> > On TOMEE-3952, are you open to a different task? One of the first
> > things
> > I'll do with TOMEE-3947 is replace the code that parses keys and
> > either our
> > code will conflict and I'll likely end up needing to rewrite your
> > code.
> > 
> > Are you at all interested in exploring the spec requirements around
> > TOMEE-3948?  I've never worked with encrypted JWTs before, so if
> > you
> > haven't either we're both equally unprepared :)
> > 
> > What would be really useful is having you read that part of the
> > spec, look
> > at the TCK to see what kind of encrypted tokens there are, then see
> > if you
> > can create some code in TomEE to decrypt the token (ideally not
> > adding a
> > dep on another library).  Doesn't matter if the code is wired into
> > TomEE or
> > duplicates code in TomEE, I can help with that part.  You could
> > just throw
> > the code anywhere under here:
> > 
> >  -
> > https://github.com/apache/tomee/tree/master/mp-jwt/src/main/java/org/apache/tomee/microprofile/jwt
> > 
> > And add a test case here:
> > 
> >  -
> > https://github.com/apache/tomee/tree/master/mp-jwt/src/test/java/org/apache/tomee/microprofile/jwt
> > 
> > The test can be a plain java, no-tomee, test that decrypts the
> > encrypted
> > JWTs from the TCK.  The JWTs and keys could just be copy/pasted
> > into the
> > test case.  That would help me see what needs to be done and have
> > that
> > first prototype of code to work from to see what would need to get
> > wired in
> > and where.  We could potentially collaborate on that part too.
> > 
> > Does that sound like something that would be fun to work on?
> > 
> > 
> > -David
> > 
> > 
> > > On May 10, 2022, at 3:33 PM, Memo Díaz Solis 
> > > wrote:
> > > 
> > > Hello David. I'd like to work on some of them. So if you don't
> > > mind, I'd
> > > like to start with TOMEE-3952.
> > > 
> > > 
> > > 
> > > El mar, 10 may 2022 a las 12:00, David Blevins (<
> > > david.blev...@gmail.com
> > > )
> > > escribió:
> > > 
> > > > I'm starting to take a look at what we need to implement
> > > > MicroProfile
> > JWT
> > > > 2.0 support.
> > > > 
> > > > There are no new requirements in 2.0 itself.  That version was
> > > > largely
> > > > created to communicate MicroProfile overall upgraded from
> > > > Jakarta EE 8
> > to
> > > > 9.1.
> > > > 
> > > > There are a handful of new requirements 1.2 we have yet to
> > > > implement.  I
> > > > dug through the spec and made this list:
> > > > 
> > > > - TOMEE-3947   Elliptic Curve ES256 signature algorithm
> > > > - TOMEE-3948   Decryption of JWTs using RSA-OAEP and A256GCM
> > > > algorithms
> > > > - TOMEE-3949   Support for JWT audience aud claim
> > > > - TOMEE-3950   Support for JWT token cookies
> > > > - TOMEE-3951   JWT token groups claim is now optional
> > > > - TOMEE-3952   Deprecate RSA keys of 1024 bit length
> > > > 
> > > > These all sit as subtasks of this JIRA issue:
> > > > 
> > > > - https://issues.apache.org/jira/browse/TOMEE-3946
> > > > "MicroProfile JWT
> > 2.0
> > > > Support"
> > > > 
> > > > I'm grabbing TOMEE-3947 Elliptic Curve ES256 signature
> > > > algorithm
> > > > 
> > > > If anyone would like to work on any of the other items, let me
> > > > know and
> > > > I'll assign it to you.
> > > > 
> > > > 
> > > > -David
> > > > 
> > > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache TomEE Patch Plugin 0.9

[Zowalla, Richard]

We have enough binding votes (JL, Jon, Cesar) to proceed with it?

Gruß
Richard

Am Donnerstag, dem 05.05.2022 um 22:08 +0200 schrieb Jean-Louis
Monteiro:
> +1
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Thu, May 5, 2022 at 4:52 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
> > +1
> > 
> > Jon
> > 
> > On Tue, May 3, 2022 at 10:01 AM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> > 
> > > Hi,
> > > 
> > > I'd like to vote Apache TomEE Patch Plugin 0.9 up for vote. The
> > > changes
> > are
> > > fairly minimal and are meant to help with Maven new versions.
> > > 
> > > Again, big thank you Richard for putting this together.
> > > 
> > > Changes:
> > > 
> > > - Fix for TOMEE-3903 (Don't attach *.tar.gz files multiple times)
> > > 
> > > Sources:
> > > 
> > > https://dist.apache.org/repos/dist/dev/tomee/staging-1201/
> > > 
> > > Staging Nexus Repository:
> > > 
> > > https://repository.apache.org/content/repositories/orgapachetomee-1201/
> > > 
> > > Tag:
> > > 
> > > 
> > > 
> > https://github.com/apache/tomee-patch-plugin/releases/tag/tomee-patch-parent-0.9
> > > Please vote to approve this release:
> > > [ ] +1 Approve the release
> > > [ ] -1 Don't approve the release (please provide specific
> > > comments)
> > > 
> > > This vote will be open for at least 72 hours.
> > > 
> > > Jean-Louis
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: How Can I Help ?

[Zowalla, Richard]

If you are seeking for help / guideance for solving your wsdl/404
issue, it might be worth to (a) subscribe and (b) write to

us...@tomee.apache.org

Add as much as explanation as possible and - which would be the most
beneficial thing - add a small self containing code example / project
on GitHub, which reproduces the issue. 

We have a lot of very experienced users on users@, so it could also be
possible, that there are people, who had the same issue you are
encounter and might have a "quick fix" in their heads. 

The dev@ list is used for technical discussion while working on
features / bugs / enhancements, etc :)

From a practical point of view: I would try to get some more log /
trace details from TomEE to see, what goes wrong, i.e. printing the
wsdl link, etc. 

Gruß
Richard




Am Montag, dem 09.05.2022 um 00:24 -0600 schrieb AD:
> Thank you so much Richard or giving me an overall area of work ,
> sounds
> very interesting to me.
> 
> I will take a deeper look at these and certainly get back to you.
> 
> Yes , I am facing a Tomee related issue for our project , which was
> developed for Weblogic .
> 
> We are now migrating to Tomee , strange is the deployment is so
> perfect ,
> you can't believe it , with no warning or errors . But when we try to
> hit
> the endpoint/wsdl  or an operation it shows 404 , which is so weird.
> 
> I have been spending a lot of time on tomee deployment and all its
> samples
> , on tomeetribe etc etc , but still no luck at ..but gaining lot of
> knowledge and experience
> 
> Hope I can get some ideas/inputs to solve this , so i will have
> certainly
> have time to contribute here a lot
> 
> Thank you
> -AD
> 
> On Mon, May 9, 2022 at 12:07 AM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Hi AD,
> > 
> > TomEE consumes a variety of ASF projects for specific parts of its
> > core
> > functionality.
> > 
> > Apache Geronimo provides JavaEE / JakartaEE libraries and
> > Microprofile
> > implementations [1]. A big effort would be to update the
> > Microprofile
> > implementation in Geronimo to support JakartaEE namespace (so we do
> > not
> > need to use SmallRye implementation like all the other app
> > servers).
> > There was some discussion in [2] about this topic.
> > 
> > Another examples are the dependencies currently shaded to bring
> > javax
> > -> jakarta namespace listed in [3]. Some efforts on other projects
> > (like the apache commons project) are needed in order to drop our
> > fork/shade and handle the namespace change in the related project.
> > Such
> > activities are also of great value to the TomEE community.
> > 
> > While working on the namespace change for ActiveMQ, the people over
> > there asked why we didn't support ActiveMQ Artemis yet [4]. We do
> > not
> > have integration code for Artemis, so this would also be a possible
> > area of contribution if you have the skills / experience in this
> > field.
> > 
> > Other areas of work involve upgrading / revising our current
> > examples
> > (TomEE 8.x, TomEE 9.x) by using our "BOM" approach in order to make
> > them easier to consume / understand so users do not have to think
> > about: "Which version of XY do I need to include to make it
> > work?!".
> > Some of them are using very old libraries (9+ years old)  and would
> > benefit from an upgrade to newer dependencies / versions or use
> > deprecated jks keystore formats, which need conversion to drop
> > warnings. Such activies are rather "easy" and can help to get a
> > feeling
> > for TomEE and OSS contributions in general.
> > 
> > Of course our current website and the dev/admin/migration
> > documentation
> > would also benefit from a careful review and a subsequent review
> > and
> > revise.
> > 
> > Some harder tasks involve running the TCK [5] and working on
> > plattform
> > compliance for EE9.1, i.e. fixing and working on the tests. Same is
> > true for working on the Smallrye miroprofile integration and fixing
> > tests / things. TCK tasks require some organisation / discussion
> > via
> > the list to avoid that work is conducted multiple times.
> > 
> > Perhaps, you suffer from a TomEE bug yourself and nobody did find
> > time
> > to work on it yet. That would also be a starting point to jump in.
> > 
> > As you probably see, there is always a lof of work to do. It fully
> > depends on your available time / resources. My list isn't nearly
> > complete but that is what I have directly in my 

Re: How Can I Help ?

[Zowalla, Richard]

Hi AD,

TomEE consumes a variety of ASF projects for specific parts of its core
functionality. 

Apache Geronimo provides JavaEE / JakartaEE libraries and Microprofile
implementations [1]. A big effort would be to update the Microprofile
implementation in Geronimo to support JakartaEE namespace (so we do not
need to use SmallRye implementation like all the other app servers).
There was some discussion in [2] about this topic.

Another examples are the dependencies currently shaded to bring javax
-> jakarta namespace listed in [3]. Some efforts on other projects
(like the apache commons project) are needed in order to drop our
fork/shade and handle the namespace change in the related project. Such
activities are also of great value to the TomEE community.

While working on the namespace change for ActiveMQ, the people over
there asked why we didn't support ActiveMQ Artemis yet [4]. We do not
have integration code for Artemis, so this would also be a possible
area of contribution if you have the skills / experience in this field.

Other areas of work involve upgrading / revising our current examples
(TomEE 8.x, TomEE 9.x) by using our "BOM" approach in order to make
them easier to consume / understand so users do not have to think
about: "Which version of XY do I need to include to make it work?!".
Some of them are using very old libraries (9+ years old)  and would
benefit from an upgrade to newer dependencies / versions or use
deprecated jks keystore formats, which need conversion to drop
warnings. Such activies are rather "easy" and can help to get a feeling
for TomEE and OSS contributions in general.

Of course our current website and the dev/admin/migration documentation
would also benefit from a careful review and a subsequent review and
revise. 

Some harder tasks involve running the TCK [5] and working on plattform
compliance for EE9.1, i.e. fixing and working on the tests. Same is
true for working on the Smallrye miroprofile integration and fixing
tests / things. TCK tasks require some organisation / discussion via
the list to avoid that work is conducted multiple times.

Perhaps, you suffer from a TomEE bug yourself and nobody did find time
to work on it yet. That would also be a starting point to jump in.

As you probably see, there is always a lof of work to do. It fully
depends on your available time / resources. My list isn't nearly
complete but that is what I have directly in my mind.

Gruß
Richard

[1] https://geronimo.apache.org/
[2] https://lists.apache.org/thread/gf1spvmw9lcvyry14l8qc10jxr8ot5hm
[3] https://github.com/apache/tomee/tree/master/deps
[4] https://lists.apache.org/thread/jokl6z7f798083vzjwc1brhpppyo33fc
[5] https://github.com/apache/tomee-tck


Am Freitag, dem 06.05.2022 um 20:21 -0600 schrieb AD:
> Hello Richard
> 
> Thank you so much for responding to my email request. Much
> appreciated.
> 
> Thanks for explaining in detail about how this works.
> 
> I do have experience in Java , Web services, Microservices , Azure ,
> Cloud
> development.
> 
> I do have experience in application servers as well , I have
> contributed in
> migration of Weblogic/Websphere applications to Tomcat/Tomee and
> Jboss as
> well
> 
> So I would like to know here how and where I can contribute , is it
> only in
> the Tomee world ? or is there something else as well  .
> 
> Would be great if you can brief out the areas typically where we can
> contribute
> 
> Thank you so much
> -AD
> 
> 
> 
> 
> 
> 
> 
> On Fri, May 6, 2022 at 12:00 AM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Hi AD,
> > 
> > welcome to the mailing list and TomEE community.
> > 
> > Do you have areas of expertise or a special field or topic of
> > interest,
> > you would like to contribute to?
> > 
> > We are currently working on TomEE 9. Therefore, we moved away from
> > our
> > previous byte code transformation approach and switched TomEE
> > master to
> > TomEE 9 (Jakarta).
> > 
> > While we made good progress, there is still a lot todo. The efforts
> > and
> > open tasks are tracked in [1]. A lot of effort is currently done to
> > switch the MicroProfile impl to MP Smallrye impls in order to move
> > to
> > the jakarta namespace [2] as well as to get the EE9 plattform TCK
> > running. If you are interested in contributing to our TomEE 9
> > efforts,
> > we can surely find some beginner friendly tasks in this area.
> > 
> > There was also some interest in doing another maintaince release of
> > 7.1.x with some fixes and dependency updates, which could also be
> > an
> > area for contribution [3].
> > 
> > It fully depends on your field of interest and your available
> &g

Re: How Can I Help ?

[Zowalla, Richard]

Hi AD,
 
welcome to the mailing list and TomEE community.

Do you have areas of expertise or a special field or topic of interest,
you would like to contribute to?

We are currently working on TomEE 9. Therefore, we moved away from our
previous byte code transformation approach and switched TomEE master to
TomEE 9 (Jakarta). 

While we made good progress, there is still a lot todo. The efforts and
open tasks are tracked in [1]. A lot of effort is currently done to
switch the MicroProfile impl to MP Smallrye impls in order to move to
the jakarta namespace [2] as well as to get the EE9 plattform TCK
running. If you are interested in contributing to our TomEE 9 efforts,
we can surely find some beginner friendly tasks in this area.

There was also some interest in doing another maintaince release of
7.1.x with some fixes and dependency updates, which could also be an
area for contribution [3].

It fully depends on your field of interest and your available resources
/ time, so it would be interesting to hear back from you.

Last but not least: Do not get intimidated by your first ticket. If it
ends up being too hard or just not fun, let's find something else for
you. There is always plenty of work to do.

Gruß
Richard


[1] https://issues.apache.org/jira/browse/TOMEE-3862
[2] https://lists.apache.org/thread/hdntdhwqkr91o2mszojq66qcfzszw96p
[3] https://lists.apache.org/thread/sz0kfocgd6248l2vxxgv3wjc5snh79q6



Am Donnerstag, dem 05.05.2022 um 14:00 -0600 schrieb AD:
> Hello
> 
> I am new to this group and would like to offer help in any way I can.
> 
> Please let me know
> 
> Thank you
> -AD


smime.p7s
Description: S/MIME cryptographic signature

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Yes - we already yanked it in 9.x

Gruß
Richard

Am Donnerstag, dem 05.05.2022 um 10:10 +0100 schrieb Jonathan
Gallimore:
> Sounds good. I'll drop the transformer from the 8.x branch (looks
> like we
> don't use it in 9.x), and I'll create a single example to demonstrate
> it in
> a sandbox.
> 
> Jon
> 
> On Wed, May 4, 2022 at 12:32 PM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > You are right - we can remove it imho from 8.x as we do not test
> > with
> > it and the transformed samples might not even work, e.g.
> > dependencies
> > are not migrated, etc.
> > 
> > +1 for providing a (bigger) example.
> > 
> > Gruß
> > Richard
> > 
> > Am Mittwoch, dem 04.05.2022 um 11:17 +0100 schrieb Jonathan
> > Gallimore:
> > > I've picked up a task related to the examples:
> > > https://issues.apache.org/jira/browse/TOMEE-3873. I specifically
> > > went
> > > for
> > > this, as I added the Eclipse Transformer to the build for a
> > > number of
> > > examples in the past, back when we were doing the transformation
> > > process on
> > > TomEE itself. The drawbacks here is that any tests in the
> > > examples
> > > run on
> > > the javax code, and we just "assume" that the transformed
> > > artifact
> > > works. I
> > > would suggest removing that for the master build, as it just
> > > takes
> > > build
> > > time, and the examples should be transformed from javax to
> > > jakarta at
> > > source (if they aren't already). On the TomEE 8 build, we could
> > > select a
> > > few examples (no need to do them all) and find a way to run the
> > > tests
> > > on
> > > both javax and jakarta versions of TomEE.
> > > 
> > > Additionally, it would likely be useful to add documentation to
> > > this.
> > > If we
> > > also wanted a bigger example application that specifically covers
> > > transformation, I could look at that too.
> > > 
> > > What do you think?
> > > 
> > > Jon
> > > 
> > > 
> > > 
> > > On Tue, Mar 22, 2022 at 12:58 PM Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > I've been working for quite a long time on TomEE 9.x, and it's
> > > > been
> > > > more
> > > > challenging and painful than I was expecting. I thought it
> > > > would be
> > > > good to
> > > > give you some sort of status.
> > > > 
> > > > I created a PR for the work. As a reminder, since Java EE moved
> > > > to
> > > > Eclipse
> > > > to become Jakarta EE, we had a switch from javax.* namespace to
> > > > jakarta.*
> > > > namespace. This is an impacting change, since all applications
> > > > and
> > > > applications servers are built on top of it.
> > > > 
> > > > In TomEE, we decided to do that change in TomEE. We had
> > > > previously
> > > > a
> > > > bytecode change approach like an application could do. It
> > > > worked
> > > > and we
> > > > were able to get certified. But it had a lot of limitations, so
> > > > we
> > > > had to
> > > > do the migration in the code and fix all compatibility issues.
> > > > 
> > > > Here is the PR https://github.com/apache/tomee/pull/814
> > > > It has 90+ commits and nearly 5000 files touched (added,
> > > > removed,
> > > > updated).
> > > > I understand it's a lot and it makes it almost impossible to
> > > > review. But I
> > > > did not see much approaches in this scenario to create smaller
> > > > PRs.
> > > > 
> > > > I created a Jenkins build though available at
> > > > https://ci-builds.apache.org/job/Tomee/job/master-build-quick-9.x/
> > > > 
> > > > It makes it possible to track the progress. There have been
> > > > steps
> > > > forward
> > > > and steps backward.
> > > > 
> > > > All the code does not sit under TomEE, we use a bunch of third
> > > > party
> > > > projects and libraries. I have been able to contribute, publish
> > > > jakarta
> > > > compatible versions and get releases for some of them (Jakarta

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

You are right - we can remove it imho from 8.x as we do not test with
it and the transformed samples might not even work, e.g. dependencies
are not migrated, etc.

+1 for providing a (bigger) example.

Gruß
Richard

Am Mittwoch, dem 04.05.2022 um 11:17 +0100 schrieb Jonathan Gallimore:
> I've picked up a task related to the examples:
> https://issues.apache.org/jira/browse/TOMEE-3873. I specifically went
> for
> this, as I added the Eclipse Transformer to the build for a number of
> examples in the past, back when we were doing the transformation
> process on
> TomEE itself. The drawbacks here is that any tests in the examples
> run on
> the javax code, and we just "assume" that the transformed artifact
> works. I
> would suggest removing that for the master build, as it just takes
> build
> time, and the examples should be transformed from javax to jakarta at
> source (if they aren't already). On the TomEE 8 build, we could
> select a
> few examples (no need to do them all) and find a way to run the tests
> on
> both javax and jakarta versions of TomEE.
> 
> Additionally, it would likely be useful to add documentation to this.
> If we
> also wanted a bigger example application that specifically covers
> transformation, I could look at that too.
> 
> What do you think?
> 
> Jon
> 
> 
> 
> On Tue, Mar 22, 2022 at 12:58 PM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> 
> > Hi,
> > 
> > I've been working for quite a long time on TomEE 9.x, and it's been
> > more
> > challenging and painful than I was expecting. I thought it would be
> > good to
> > give you some sort of status.
> > 
> > I created a PR for the work. As a reminder, since Java EE moved to
> > Eclipse
> > to become Jakarta EE, we had a switch from javax.* namespace to
> > jakarta.*
> > namespace. This is an impacting change, since all applications and
> > applications servers are built on top of it.
> > 
> > In TomEE, we decided to do that change in TomEE. We had previously
> > a
> > bytecode change approach like an application could do. It worked
> > and we
> > were able to get certified. But it had a lot of limitations, so we
> > had to
> > do the migration in the code and fix all compatibility issues.
> > 
> > Here is the PR https://github.com/apache/tomee/pull/814
> > It has 90+ commits and nearly 5000 files touched (added, removed,
> > updated).
> > I understand it's a lot and it makes it almost impossible to
> > review. But I
> > did not see much approaches in this scenario to create smaller PRs.
> > 
> > I created a Jenkins build though available at
> > https://ci-builds.apache.org/job/Tomee/job/master-build-quick-9.x/
> > 
> > It makes it possible to track the progress. There have been steps
> > forward
> > and steps backward.
> > 
> > All the code does not sit under TomEE, we use a bunch of third
> > party
> > projects and libraries. I have been able to contribute, publish
> > jakarta
> > compatible versions and get releases for some of them (Jakarta EE
> > APIs Uber
> > jar, Geronimo Connectors and Transaction Manager, Geronimo Config,
> > Health,
> > Metrics, OpenTracing, OpenAPI. OpenJPA, BVal, and OpenWebBeans will
> > be
> > released soon.
> > 
> > The big parts is CXF, and ActiveMQ. I had to get them done in TomEE
> > and
> > update all group/artifact ids. It's under deps, alongside with SXC,
> > DBCP,
> > and others.
> > 
> > In terms of removal, I tried to remove old stuff like SAAJ Axis 1
> > integration, JAX RPC, Management J2EE and a couple of other old
> > things.
> > 
> > A lot of other libraries got updated to their latest version when
> > available
> > in the new jakarta namespace.
> > 
> > I'm starting to get all the build stable and many modules are
> > passing now,
> > including all CXF webservices, OpenEJB Core, and others. I can get
> > a build
> > and run TomEE.
> > 
> > Goal is to get a green build asap so we can start working on TCK.
> > The "quick" build is now green. Working on the full build.
> > 
> > I'll soon be creating a branch for TomEE 8.x maintenance and merge
> > the PR.
> > I'm hoping we can then have small PRs or at least more people
> > working in
> > parallel.
> > 
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Thanks, Cesar. I left some comments.

Am Montag, dem 02.05.2022 um 21:01 -0600 schrieb Cesar Hernandez:
> I created https://issues.apache.org/jira/browse/TOMEE-3932 and the PR
> with
> the first iteration of the document is ready for review.
> https://github.com/apache/tomee/pull/878
> 
> El sáb, 30 abr 2022 a las 0:26, Zowalla, Richard (<
> richard.zowa...@hs-heilbronn.de>) escribió:
> 
> > Sounds good: +1
> > 
> > Am Freitag, dem 29.04.2022 um 11:06 +0200 schrieb Jean-Louis
> > Monteiro:
> > > That sounds great Cesar. Thanks
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > > 
> > > 
> > > On Fri, Apr 29, 2022 at 5:48 AM Cesar Hernandez <
> > > cesargu...@gmail.com
> > > wrote:
> > > 
> > > > Thank you for the list, Richard,
> > > > 
> > > > If there is no objection, I propose to create a
> > > > https://github.com/apache/tomee/javaxToJakartaNamespace.adoc  t
> > > > o
> > > > keep
> > > > track
> > > > of the shaded versions we currently have, common dependencies
> > > > that
> > > > will
> > > > need to be updated, and strategies to troubleshooting common
> > > > issues
> > > > and
> > > > link to the main epic
> > > > https://issues.apache.org/jira/browse/TOMEE-3862.
> > > > 
> > > > WDYT?
> > > > 
> > > > 
> > > > 
> > > > El mié, 27 abr 2022 a las 0:23, Zowalla, Richard (<
> > > > richard.zowa...@hs-heilbronn.de>) escribió:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > I am not aware of any public reference list. There are some
> > > > > things,
> > > > > which floated around the mailing list or in the heads, which
> > > > > are:
> > > > > 
> > > > > - Javamail is currently broken. We need to have a jakarta
> > > > > compatible
> > > > > version of Geronimo Javamail. This currently breaks 2
> > > > > examples
> > > > > and
> > > > > prevents platform tck from running.
> > > > > 
> > > > > - Deltaspike / Kratzo examples require dependency upgrades,
> > > > > i.e.
> > > > > MVC
> > > > > 2.0 + Jakarta version of Deltaspike.
> > > > > 
> > > > > - Micro Profile examples are broken due to the ongoing
> > > > > integration work
> > > > > of SmallRye impls. If the integration is done, we can fix
> > > > > them.
> > > > > 
> > > > > - If Hibernate is used, we either need to upgrade to 6.0.0
> > > > > _or_
> > > > > use the
> > > > > Jakarta artifact from the 5.6.x series. In some examples, we
> > > > > still use
> > > > > Hibernate 4, so the upgrade also requires to deal with
> > > > > "tomee.jpa.factory.lazy".
> > > > > 
> > > > > - Check for "http" repositories to avoid the default http
> > > > > blocker
> > > > > in
> > > > > newer Maven versions.
> > > > > 
> > > > > Gruß
> > > > > Richard
> > > > > 
> > > > > 
> > > > > Am Dienstag, dem 26.04.2022 um 21:28 -0600 schrieb Cesar
> > > > > Hernandez:
> > > > > > Hi all,
> > > > > > 
> > > > > > Late last week I started to pick and create sub-task
> > > > > > related to
> > > > > > https://issues.apache.org/jira/browse/TOMEE-3862.
> > > > > > The current CI master status [1] has helped me to identify
> > > > > > tests that
> > > > > > need
> > > > > > fixes, examples that need dependencies updates to match the
> > > > > > javax. ->
> > > > > > jakarta , etc.
> > > > > > 
> > > > > > Do we have a place where we can check the list of knowing-
> > > > > > Issue
> > > > > > and
> > > > > > knowing-fixes a contributor can take as a reference when
> > > > > > trying
> > > > > > to
> > > > > > fix a
> > > > > > subtask from TOMEE-3862 ?
> > > > > > F

Re: OpenJDK is no more?

[Zowalla, Richard]

Thanks Rod!!

Am Montag, dem 02.05.2022 um 17:33 + schrieb Jenkins, Rodney J
(Rod):
> All,
> 
> I have added the Semeru images for Java 11 and 17 for TomEE 8 and 9.
> 
> Anything else anyone wants?
> 
> Thanks,
> Rod.
> 
> 
> 
> On 4/30/22, 12:35 PM, "Zowalla, Richard" <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> Nationwide Information Security Warning: This is an EXTERNAL
> email. Use CAUTION before clicking on links, opening attachments, or
> responding. (Sender: 
> dev-return-29380-JENKIR14=nationwide@tomee.apache.org)
> 
> -
> -
> 
> 
> Maybe 11 + 17 for OpenJ9/Semeru? ;)
> 
> Thanks.
> 
> Gruß
> Richard
> 
> Von: Jenkins, Rodney J (Rod) 
> Gesendet: Samstag, 30. April 2022 19:12:40
> An: dev@tomee.apache.org
> Betreff: Re: Re: Re: OpenJDK is no more?
> 
> Alex,
> 
> That explains why I did not see it, lol.
> 
> 
> 
> All,
> 
> I have created this PR for review:  
> https://github.com/tomitribe/docker-tomee/pull/66
> 
> This is not final, so if we want to add Semeru, I just need to
> know what java versions we would like to add.
> 
> Thank you,
> Rod.
> 
> 
> On 4/30/22, 11:16 AM, "Alex The Rocker" 
> wrote:
> 
> Nationwide Information Security Warning: This is an EXTERNAL
> email. Use CAUTION before clicking on links, opening attachments, or
> responding. (Sender: 
> dev-return-29378-JENKIR14=nationwide@tomee.apache.org)
> 
> -
> -
> 
> 
> Hi Rod,
> 
> You won't find any Semeru/OpenJ9 image based on Alpine,
> because this
> JVM is not supporter on Alpine (alas...)
> 
> Thanks,
> Alex
> 
> Le sam. 30 avr. 2022 à 18:10, Jenkins, Rodney J (Rod)
>  a écrit :
> >
> > Richard,
> >
> > I am fine with providing a Semeru/OpenJ9.  Would we want
> that or 8, 11, and 17?
> >
> > I do not see an alpine image, so it would just be adding a
> ubuntu image.
> >
> > Rod.
> >
> >
> > On 4/30/22, 1:30 AM, "Zowalla, Richard" <
> richard.zowa...@hs-heilbronn.de> wrote:
> >
> > Nationwide Information Security Warning: This is an
> EXTERNAL email. Use CAUTION before clicking on links, opening
> attachments, or responding. (Sender: 
> dev-return-29375-JENKIR14=nationwide@tomee.apache.org)
> >
> > ---
> ---
> >
> >
> > Hi,
> >
> > I think, that Alpine would be a great addition to
> shrink the images
> > sizes if it isn't too much work.
> >
> > I am also wondering, if we should provide a
> Semeru/OpenJ9
> > runtime - but I guess, that there isn't too much need
> for it, so it is
> > super low prio :D
> >
> > Gruß
> > Richard
> >
> >
> >
> > Am Freitag, dem 29.04.2022 um 21:18 + schrieb
> Jenkins, Rodney J
> > (Rod):
> > > Hello all,
> > >
> > > There is more information on the PR I noted earlier.
> > >
> > > Essentially, OpenJDK 17 is being dereplicated.  In
> addition OpenJDK 8
> > > and OpenJDK 11, "are not updated on an extreme
> priority."
> > >
> > > Given this new information, I propose the following:
> > > Move immediately to Temurin for Java 17.  (There have
> been many +1
> > > votes for this)
> > > We add a Temurin option for Java 8 and 11 should we
> lose support for
> > > those.  We would still leave OpenJDK as the default.
> > >
> > > These additional images will be using Ubuntu as the
> OS for
> > > Temurin.  OpenJDK will stay with Debian.  As long as
> we are on the
> > > topic of OS, there has been demand for Alpine for
> smaller images.  I
> > > am also willing to add an Alpine option.
>

AW: Re: Re: OpenJDK is no more?

[Zowalla, Richard]

Maybe 11 + 17 for OpenJ9/Semeru? ;)

Thanks.

Gruß
Richard

Von: Jenkins, Rodney J (Rod) 
Gesendet: Samstag, 30. April 2022 19:12:40
An: dev@tomee.apache.org
Betreff: Re: Re: Re: OpenJDK is no more?

Alex,

That explains why I did not see it, lol.



All,

I have created this PR for review:  
https://github.com/tomitribe/docker-tomee/pull/66

This is not final, so if we want to add Semeru, I just need to know what java 
versions we would like to add.

Thank you,
Rod.


On 4/30/22, 11:16 AM, "Alex The Rocker"  wrote:

Nationwide Information Security Warning: This is an EXTERNAL email. Use 
CAUTION before clicking on links, opening attachments, or responding. (Sender: 
dev-return-29378-JENKIR14=nationwide@tomee.apache.org)


--


Hi Rod,

You won't find any Semeru/OpenJ9 image based on Alpine, because this
JVM is not supporter on Alpine (alas...)

Thanks,
Alex

Le sam. 30 avr. 2022 à 18:10, Jenkins, Rodney J (Rod)
 a écrit :
>
> Richard,
>
> I am fine with providing a Semeru/OpenJ9.  Would we want that or 8, 11, 
and 17?
>
> I do not see an alpine image, so it would just be adding a ubuntu image.
>
> Rod.
>
>
> On 4/30/22, 1:30 AM, "Zowalla, Richard"  
wrote:
>
> Nationwide Information Security Warning: This is an EXTERNAL email. 
Use CAUTION before clicking on links, opening attachments, or responding. 
(Sender: dev-return-29375-JENKIR14=nationwide@tomee.apache.org)
>
> 
--
>
>
> Hi,
>
> I think, that Alpine would be a great addition to shrink the images
> sizes if it isn't too much work.
>
> I am also wondering, if we should provide a Semeru/OpenJ9
> runtime - but I guess, that there isn't too much need for it, so it is
> super low prio :D
>
> Gruß
> Richard
>
>
>
> Am Freitag, dem 29.04.2022 um 21:18 + schrieb Jenkins, Rodney J
> (Rod):
> > Hello all,
> >
> > There is more information on the PR I noted earlier.
> >
> > Essentially, OpenJDK 17 is being dereplicated.  In addition OpenJDK 
8
> > and OpenJDK 11, "are not updated on an extreme priority."
> >
> > Given this new information, I propose the following:
> > Move immediately to Temurin for Java 17.  (There have been many +1
> > votes for this)
> > We add a Temurin option for Java 8 and 11 should we lose support for
> > those.  We would still leave OpenJDK as the default.
> >
> > These additional images will be using Ubuntu as the OS for
> > Temurin.  OpenJDK will stay with Debian.  As long as we are on the
> > topic of OS, there has been demand for Alpine for smaller images.  I
> > am also willing to add an Alpine option.
> >
> > I am going to start on these this weekend in hope of having a PR
> > ready for review middle of next week.
> >
> > If anyone has thoughts or comments, please chime in.
> >
> > Thanks,
> > Rod.
> >
> >
> > On 4/27/22, 6:22 PM, "Jenkins, Rodney J (Rod)" <
> > jenki...@nationwide.com> wrote:
> >
> > Nationwide Information Security Warning: This is an EXTERNAL
> > email. Use CAUTION before clicking on links, opening attachments, or
> > responding. (Sender:
> > dev-return-29359-JENKIR14=nationwide@tomee.apache.org)
> >
> > 
-
> > -
> >
> >
> > All,
> >
> > I was notified of the pull request below.  Long story short:   
We
> > need to choose a different JDK to run on our docker images.
> >
> > At the moment I'm not sure what all the choices are.   When I
> > looked at this before, I suggested Eclipse Temurin.
> >
> > Does anyone have a preference or others to consider?
> >
> > Thanks,
> > Rod.
> >
> >
> > https://github.com/docker-library/openjdk/pull/495
> >
>

Re: OpenJDK is no more?

[Zowalla, Richard]

Hi,

I think, that Alpine would be a great addition to shrink the images
sizes if it isn't too much work.

I am also wondering, if we should provide a Semeru/OpenJ9
runtime - but I guess, that there isn't too much need for it, so it is
super low prio :D

Gruß
Richard



Am Freitag, dem 29.04.2022 um 21:18 + schrieb Jenkins, Rodney J
(Rod):
> Hello all,
> 
> There is more information on the PR I noted earlier.
> 
> Essentially, OpenJDK 17 is being dereplicated.  In addition OpenJDK 8
> and OpenJDK 11, "are not updated on an extreme priority."
> 
> Given this new information, I propose the following:
> Move immediately to Temurin for Java 17.  (There have been many +1
> votes for this)
> We add a Temurin option for Java 8 and 11 should we lose support for
> those.  We would still leave OpenJDK as the default.
> 
> These additional images will be using Ubuntu as the OS for
> Temurin.  OpenJDK will stay with Debian.  As long as we are on the
> topic of OS, there has been demand for Alpine for smaller images.  I
> am also willing to add an Alpine option.
> 
> I am going to start on these this weekend in hope of having a PR
> ready for review middle of next week.
> 
> If anyone has thoughts or comments, please chime in.
> 
> Thanks,
> Rod.
> 
> 
> On 4/27/22, 6:22 PM, "Jenkins, Rodney J (Rod)" <
> jenki...@nationwide.com> wrote:
> 
> Nationwide Information Security Warning: This is an EXTERNAL
> email. Use CAUTION before clicking on links, opening attachments, or
> responding. (Sender: 
> dev-return-29359-JENKIR14=nationwide@tomee.apache.org)
> 
> -
> -
> 
> 
> All,
> 
> I was notified of the pull request below.  Long story short:   We
> need to choose a different JDK to run on our docker images.
> 
> At the moment I'm not sure what all the choices are.   When I
> looked at this before, I suggested Eclipse Temurin.
> 
> Does anyone have a preference or others to consider?
> 
> Thanks,
> Rod.
> 
> 
> https://github.com/docker-library/openjdk/pull/495
> 

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Sounds good: +1 

Am Freitag, dem 29.04.2022 um 11:06 +0200 schrieb Jean-Louis Monteiro:
> That sounds great Cesar. Thanks
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Fri, Apr 29, 2022 at 5:48 AM Cesar Hernandez  >
> wrote:
> 
> > Thank you for the list, Richard,
> > 
> > If there is no objection, I propose to create a
> > https://github.com/apache/tomee/javaxToJakartaNamespace.adoc  to
> > keep
> > track
> > of the shaded versions we currently have, common dependencies that
> > will
> > need to be updated, and strategies to troubleshooting common issues
> > and
> > link to the main epic 
> > https://issues.apache.org/jira/browse/TOMEE-3862.
> > 
> > WDYT?
> > 
> > 
> > 
> > El mié, 27 abr 2022 a las 0:23, Zowalla, Richard (<
> > richard.zowa...@hs-heilbronn.de>) escribió:
> > 
> > > Hi,
> > > 
> > > I am not aware of any public reference list. There are some
> > > things,
> > > which floated around the mailing list or in the heads, which are:
> > > 
> > > - Javamail is currently broken. We need to have a jakarta
> > > compatible
> > > version of Geronimo Javamail. This currently breaks 2 examples
> > > and
> > > prevents platform tck from running.
> > > 
> > > - Deltaspike / Kratzo examples require dependency upgrades, i.e.
> > > MVC
> > > 2.0 + Jakarta version of Deltaspike.
> > > 
> > > - Micro Profile examples are broken due to the ongoing
> > > integration work
> > > of SmallRye impls. If the integration is done, we can fix them.
> > > 
> > > - If Hibernate is used, we either need to upgrade to 6.0.0 _or_
> > > use the
> > > Jakarta artifact from the 5.6.x series. In some examples, we
> > > still use
> > > Hibernate 4, so the upgrade also requires to deal with
> > > "tomee.jpa.factory.lazy".
> > > 
> > > - Check for "http" repositories to avoid the default http blocker
> > > in
> > > newer Maven versions.
> > > 
> > > Gruß
> > > Richard
> > > 
> > > 
> > > Am Dienstag, dem 26.04.2022 um 21:28 -0600 schrieb Cesar
> > > Hernandez:
> > > > Hi all,
> > > > 
> > > > Late last week I started to pick and create sub-task related to
> > > > https://issues.apache.org/jira/browse/TOMEE-3862.
> > > > The current CI master status [1] has helped me to identify
> > > > tests that
> > > > need
> > > > fixes, examples that need dependencies updates to match the
> > > > javax. ->
> > > > jakarta , etc.
> > > > 
> > > > Do we have a place where we can check the list of knowing-Issue 
> > > > and
> > > > knowing-fixes a contributor can take as a reference when trying
> > > > to
> > > > fix a
> > > > subtask from TOMEE-3862 ?
> > > > For example, today I faced a javax/servlet issue [2] that
> > > > required
> > > > some
> > > > dependencies replacements like jstl [3 ] with
> > > > jakarta.servlet.jsp.jstl-api
> > > > [4] and taglibs:standard [5] with taglibs-shade [6].
> > > > 
> > > > 
> > > > [1]
> > > > https://ci-builds.apache.org/job/Tomee/job/master-build-full/
> > > > 
> > > > [2]
> > > > 
> > > > Caused by: java.lang.NoClassDefFoundError:
> > > > javax/servlet/jsp/tagext/TagSupport
> > > > 
> > > > 
> > > > [3]
> > > > javax.servlet
> > > > jstl
> > > > 1.1.2
> > > > 
> > > > [4]
> > > > jakarta.servlet.jsp.jstl
> > > > jakarta.servlet.jsp.jstl-api
> > > > 2.0.0
> > > > 
> > > > [5]
> > > > taglibs
> > > > standard
> > > > 1.1.2
> > > > 
> > > > [6]
> > > > org.apache.tomee
> > > > taglibs-shade
> > > > 9.0.0-M8-SNAPSHOT
> > > > 
> > > > 
> > > > El mié, 30 mar 2022 a las 1:20, Jean-Louis Monteiro (<
> > > > jlmonte...@tomitribe.com>) escribió:
> > > > 
> > > > > Thanks Richard.
> > > > > 
> > > > > I got personal issues with my computer and it's taking a bit
> > > > > of
> > > > > tim

Re: OpenJDK is no more?

[Zowalla, Richard]

+1

Am Donnerstag, dem 28.04.2022 um 11:19 +0200 schrieb Jean-Louis
Monteiro:
> Eclipse is fine.
> Thanks
> 
> Le jeu. 28 avr. 2022 à 01:22, Jenkins, Rodney J (Rod) <
> jenki...@nationwide.com> a écrit :
> 
> > All,
> > 
> > I was notified of the pull request below.  Long story short:   We
> > need to
> > choose a different JDK to run on our docker images.
> > 
> > At the moment I'm not sure what all the choices are.   When I
> > looked at
> > this before, I suggested Eclipse Temurin.
> > 
> > Does anyone have a preference or others to consider?
> > 
> > Thanks,
> > Rod.
> > 
> > 
> > https://github.com/docker-library/openjdk/pull/495
> > 

Re: How can I help?

[Zowalla, Richard]

Hi,

it would certainly help to track these issues as an issue.

Maybe they are already solved (as the code has evolved) but maybe not,
so it would be good to have them.

Gruß
Richard

Am Dienstag, dem 26.04.2022 um 21:54 +0200 schrieb Zoltán Tichov:
> Hi Richard!
> 
> I have found two errors in Tomee 9.0.0-M7. Should I make tickets for
> these
> errors and try to fix them?
> Although they may have been fixed in the next version (9.0.0-M8)
> 
> Zoltán
> 
> On Sun, Apr 24, 2022 at 11:06 AM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Hi Zoltán,
> > 
> > It's very great from you and it's truly awesome when a long time
> > user
> > of TomEE decides to contribute :)
> > 
> > First of all, do not get intimidated by your first ticket. If it
> > ends
> > up being too hard or just not fun, let's find something else for
> > you.
> > There is always plenty of work to do.
> > 
> > We are currently working on TomEE 9. Therefore, we moved away from
> > our
> > previous byte code transformation approach and switched TomEE
> > master to
> > TomEE 9 (Jakarta).
> > 
> > While we made good progress, there is still a lot todo. The efforts
> > and
> > open tasks are tracked in [1]. A lot of effort is currently done to
> > switch the MicroProfile impl to MP Smallrye impls in order to move
> > to
> > the jakarta namespace [2].
> > 
> > If you are interested in contributing to our TomEE 9 efforts, we
> > can
> > surely find some beginner friendly tasks in this area.
> > 
> > Gruß
> > Richard
> > 
> > 
> > [1] https://issues.apache.org/jira/browse/TOMEE-3862
> > [2] 
> > https://lists.apache.org/thread/hdntdhwqkr91o2mszojq66qcfzszw96p
> > 
> > 
> > Am Samstag, dem 23.04.2022 um 20:21 +0200 schrieb Zoltán Tichov:
> > > Hi!
> > > 
> > > I live in Hungary. I am working at an IT company as a software
> > > developer, I
> > > develop java
> > > webapps with jsf (PrimeFaces) and microservice like apps without
> > > any
> > > container technology
> > > and Oracle database.
> > > 
> > > We want to switch to jakarta ee 9 at the company, but
> > > unfortunately
> > > we ran
> > > into problems with tomee 9 and I would like to contribute to
> > > fixing
> > > these
> > > bugs and possibly improving tomee jakarta 10. (I'm sorry to read
> > > on
> > > another
> > > tomee mailing list, that you had to skip jakarta ee 8 and 9
> > > compliance
> > > entirely)
> > > I use java 11 and netbeans on windows 10. If we don't have to, we
> > > don't
> > > want to use another app server because we've been using tomee
> > > since
> > > 1.7.3.
> > > 
> > > Best regards: Zoltán Tichov

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Hi,

I am not aware of any public reference list. There are some things,
which floated around the mailing list or in the heads, which are:

- Javamail is currently broken. We need to have a jakarta compatible
version of Geronimo Javamail. This currently breaks 2 examples and
prevents platform tck from running. 

- Deltaspike / Kratzo examples require dependency upgrades, i.e. MVC
2.0 + Jakarta version of Deltaspike.

- Micro Profile examples are broken due to the ongoing integration work
of SmallRye impls. If the integration is done, we can fix them.

- If Hibernate is used, we either need to upgrade to 6.0.0 _or_ use the
Jakarta artifact from the 5.6.x series. In some examples, we still use
Hibernate 4, so the upgrade also requires to deal with
"tomee.jpa.factory.lazy". 

- Check for "http" repositories to avoid the default http blocker in
newer Maven versions. 

Gruß
Richard


Am Dienstag, dem 26.04.2022 um 21:28 -0600 schrieb Cesar Hernandez:
> Hi all,
> 
> Late last week I started to pick and create sub-task related to
> https://issues.apache.org/jira/browse/TOMEE-3862.
> The current CI master status [1] has helped me to identify tests that
> need
> fixes, examples that need dependencies updates to match the javax. ->
> jakarta , etc.
> 
> Do we have a place where we can check the list of knowing-Issue and
> knowing-fixes a contributor can take as a reference when trying to
> fix a
> subtask from TOMEE-3862 ?
> For example, today I faced a javax/servlet issue [2] that required
> some
> dependencies replacements like jstl [3 ] with
> jakarta.servlet.jsp.jstl-api
> [4] and taglibs:standard [5] with taglibs-shade [6].
> 
> 
> [1]
> https://ci-builds.apache.org/job/Tomee/job/master-build-full/
> 
> [2]
> 
> Caused by: java.lang.NoClassDefFoundError:
> javax/servlet/jsp/tagext/TagSupport
> 
> 
> [3]
> javax.servlet
> jstl
> 1.1.2
> 
> [4]
> jakarta.servlet.jsp.jstl
> jakarta.servlet.jsp.jstl-api
> 2.0.0
> 
> [5]
> taglibs
> standard
> 1.1.2
> 
> [6]
> org.apache.tomee
> taglibs-shade
> 9.0.0-M8-SNAPSHOT
> 
> 
> El mié, 30 mar 2022 a las 1:20, Jean-Louis Monteiro (<
> jlmonte...@tomitribe.com>) escribió:
> 
> > Thanks Richard.
> > 
> > I got personal issues with my computer and it's taking a bit of
> > time to set
> > everything up again.
> > 
> > 
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> > 
> > 
> > On Wed, Mar 30, 2022 at 8:45 AM Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > > Update regarding TOMEE-3879: We were missing --add-opens options
> > > in the
> > > failover tests to run with Java 11+ - we added it to the bat / sh
> > > scripts of openejb-standalone. However, bat / sh is not used in
> > > the
> > > failover tests.
> > > 
> > > I added the options in the tests, so TOMEE-3879 is fixed now.
> > > 
> > > Gruß
> > > Richard
> > > 
> > > Am Dienstag, dem 29.03.2022 um 06:53 + schrieb Zowalla,
> > > Richard:
> > > > Hi,
> > > > 
> > > > to follow up on TOMEE-3879 [1]: I add some more context to the
> > > > Jira.
> > > > The permissions do not matter as we are not invoking the
> > > > scripts in
> > > > bin/* in the failover itests (itests/failover).
> > > > 
> > > > We are directly booting the servers via the java command (via
> > > > Bootstrap
> > > > from openejb-core) and a lot of properties to configure it,
> > > > which
> > > > fails
> > > > (at least for me atm) with a ClassNotFoundException (see
> > > > issue). Due
> > > > to
> > > > this exception, the servers never become ready and the tests
> > > > will
> > > > just
> > > > timeout.
> > > > 
> > > > Don't have time to dig into it now but hope it helps anyone,
> > > > who will
> > > > work on it in the near future :)
> > > > 
> > > > Gruß
> > > > Richard
> > > > 
> > > > [1] https://issues.apache.org/jira/browse/TOMEE-3879
> > > > 
> > > > Am Montag, dem 28.03.2022 um 08:16 + schrieb Zowalla,
> > > > Richard:
> > > > > Heyho,
> > > > > 
> > > > > the ZIP created for TOMEE-3879 looks good to me. It has +x
> > > > > set.
> > > > > Perhaps
> > > > > it looses the info during

Re: TCK Work - Smoothing the path (was Re: How can I help?)

[Zowalla, Richard]

I slightly increased the default stack size limit of the forked test 
jvm in the related groovy script. It now works with Java 11 too.

To summarize: The documentation is updated and setting up the EE9.1 TCK
is quite easy. It basically boils down to:

(0) Ensure to have Maven and Java (11/14). 
(1) Run on a Linux / Mac OS system.
(2) Adjust the settings.xml according to the template
(3) Run the setup script (only oncE)
(4) Check that everything is available
(5) Add the TCK install into a local git repository to reset easily
without delete & extract it again and again (as a TCK run modifies the
isntallation)
(6) Run the TCK and have fun.

Nevertheless, we need to fix the javamail (javax vs jakarta) thing
first, but afterwards any new volunteer can happily start TCK work.  

Gruß
Richard


Am Dienstag, dem 26.04.2022 um 18:34 + schrieb Zowalla, Richard:
> Thanks & You are right! Running with JDK 14 works. 
> 
> JDK 17 has some issues with illegal access within the groovy code
> used. 
> 
> With JDK 14 I am hitting the Javamail issue - so the setup procedere
> basically works. That are good news.
> 
> Gruß
> Richard
> 
> 
> Am Dienstag, dem 26.04.2022 um 19:48 +0200 schrieb Jean-Louis
> Monteiro:
> > Sorry for the late reply.
> > I managed to reproduce your issue. It does not seem to be a regular
> > stackoverflow (loop without exit condition).
> > Debugging the code with some additional traces, it looks like we
> > are
> > loading jar after jar and the stack isn't big enough to handle it
> > in
> > Java
> > 11.
> > 
> > I moved to a newer JDK like 14 or 17 and it worked.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> > 
> > 
> > On Tue, Apr 26, 2022 at 7:42 PM Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > > It looks like the SQL is not the real issue here - although it is
> > > a
> > > bit
> > > confusing because the select statements look ok to me.
> > > 
> > > However, after same additional digging / fiddling arround, I am
> > > at
> > > a
> > > point, there the JVM for the tests does not startup due to an
> > > StackOverflowError [1].
> > > 
> > > I tried remote debugging via "-dj" but have no glue why I am
> > > running to
> > > this StackOverflowError during the "ant.java(...)" call in the
> > > related
> > > groovy command. I bet, that I miss a little detail - so happy to
> > > any
> > > additional input ;)
> > > 
> > > Gruß
> > > R
> > > 
> > > 
> > > [1] https://gist.github.com/rzo1/0af90723dc0c6689a6f7d7bae9d2e8da
> > > 
> > > 
> > > Am Dienstag, dem 26.04.2022 um 09:59 + schrieb Zowalla,
> > > Richard:
> > > > Hi,
> > > > 
> > > > I changed the script pointing to the released ee9.1 tck now and
> > > > updated
> > > > the README accordingly. If the instructions are followed
> > > > carefully,
> > > > it
> > > > will lead to a fresh installation.
> > > > 
> > > > In the process, I noticed, that Glassfish 6.0.0 isn't available
> > > > anymore
> > > > and is replaced by 6.2.5 - JL mentioned on Slack, that 6.2.5
> > > > should
> > > > also work.
> > > > 
> > > > I think, that we do not really need a public git repository.
> > > > Setting
> > > > it
> > > > up with the script is really straight forward. However, putting
> > > > the
> > > > TCK
> > > > installation into a local git repository makes totally sense in
> > > > order
> > > > to avoid delete / unpack cycles due to the modifications on the
> > > > installation, if the TCK is run.
> > > > 
> > > > I added some instructions in the README.
> > > > 
> > > > Currently, I am struggling with
> > > > 
> > > > [ERROR] java.sql.SQLSyntaxErrorException: Syntax error:
> > > > Encountered
> > > > "Simple_Select_Query" at line 1, column 1.
> > > > [INFO] 1130 of 1307 SQL statements executed successfully
> > > > 
> > > > when running
> > > > 
> > > > rm -rf target/ && ./runtests -Dhttps.protocols=TLSv1.1,TLSv1.2
> > > > --
> > > > ee91
> > > > --env -nc -c -U -w tomee-plume
> > > > com.sun.ts.tests.ejb30.lite.appexception

Re: Increasing Discard Old Builds strategy in CI

[Zowalla, Richard]

Afaik Jenkins is parsing the surefire report files. The log files might
also be important for the creator of the PR, so we would need to keep
them too.

Might be worth a try, I guess.

Gruß
Richard

Am Dienstag, dem 26.04.2022 um 11:15 -0700 schrieb David Blevins:
> > On Apr 26, 2022, at 10:47 AM, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > However, we need to carefully monitor the disk usage / volume used
> > as
> > INFRA has a problem if our used storage volume per jobs exceeds a
> > certain quota. 
> > 
> > We occupied 1,5T last week (cumulated over a few weeks) and they
> > were a
> > bit mad as the Jenkins CI env went out of storage.
> 
> I was going to jump in on that thread and got side tracked.
> 
> I wonder if we can do a `mvn clean` or something similar as a post
> build step.  Looks like after a build we have 2.8G used of disk space
> and once we clean that goes down to 398M.
> 
> The test case results are the obvious trick.  I'm not sure if Jenkins
> keeps those somewhere else or if we need them to keep living in the
> target directories.  If they need to stay in the target directories
> we can maybe create a script that deletes everything in target/ but
> surefire results.
> 
> If we did that, we'd use 1.5 gigabytes for 30 builds vs 10.5
> gigabytes.
> 
> Then we could just keep 30 builds regardless of days and it should be
> good.
> 
> Thoughts?
> 
> 
> -David
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: TCK Work - Smoothing the path (was Re: How can I help?)

[Zowalla, Richard]

Thanks & You are right! Running with JDK 14 works. 

JDK 17 has some issues with illegal access within the groovy code
used. 

With JDK 14 I am hitting the Javamail issue - so the setup procedere
basically works. That are good news.

Gruß
Richard


Am Dienstag, dem 26.04.2022 um 19:48 +0200 schrieb Jean-Louis Monteiro:
> Sorry for the late reply.
> I managed to reproduce your issue. It does not seem to be a regular
> stackoverflow (loop without exit condition).
> Debugging the code with some additional traces, it looks like we are
> loading jar after jar and the stack isn't big enough to handle it in
> Java
> 11.
> 
> I moved to a newer JDK like 14 or 17 and it worked.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Tue, Apr 26, 2022 at 7:42 PM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > It looks like the SQL is not the real issue here - although it is a
> > bit
> > confusing because the select statements look ok to me.
> > 
> > However, after same additional digging / fiddling arround, I am at
> > a
> > point, there the JVM for the tests does not startup due to an
> > StackOverflowError [1].
> > 
> > I tried remote debugging via "-dj" but have no glue why I am
> > running to
> > this StackOverflowError during the "ant.java(...)" call in the
> > related
> > groovy command. I bet, that I miss a little detail - so happy to
> > any
> > additional input ;)
> > 
> > Gruß
> > R
> > 
> > 
> > [1] https://gist.github.com/rzo1/0af90723dc0c6689a6f7d7bae9d2e8da
> > 
> > 
> > Am Dienstag, dem 26.04.2022 um 09:59 + schrieb Zowalla,
> > Richard:
> > > Hi,
> > > 
> > > I changed the script pointing to the released ee9.1 tck now and
> > > updated
> > > the README accordingly. If the instructions are followed
> > > carefully,
> > > it
> > > will lead to a fresh installation.
> > > 
> > > In the process, I noticed, that Glassfish 6.0.0 isn't available
> > > anymore
> > > and is replaced by 6.2.5 - JL mentioned on Slack, that 6.2.5
> > > should
> > > also work.
> > > 
> > > I think, that we do not really need a public git repository.
> > > Setting
> > > it
> > > up with the script is really straight forward. However, putting
> > > the
> > > TCK
> > > installation into a local git repository makes totally sense in
> > > order
> > > to avoid delete / unpack cycles due to the modifications on the
> > > installation, if the TCK is run.
> > > 
> > > I added some instructions in the README.
> > > 
> > > Currently, I am struggling with
> > > 
> > > [ERROR] java.sql.SQLSyntaxErrorException: Syntax error:
> > > Encountered
> > > "Simple_Select_Query" at line 1, column 1.
> > > [INFO] 1130 of 1307 SQL statements executed successfully
> > > 
> > > when running
> > > 
> > > rm -rf target/ && ./runtests -Dhttps.protocols=TLSv1.1,TLSv1.2 --
> > > ee91
> > > --env -nc -c -U -w tomee-plume
> > > com.sun.ts.tests.ejb30.lite.appexception.singleton.annotated.Clie
> > > nt
> > > 
> > > as the initial setup of the derby database seem to fail - don't
> > > have
> > > much ideas but using the search engine of trust I found an entry,
> > > that
> > > this also happened on a tck.work build long time ago.
> > > 
> > > I guess, that I am just missing a little thing to fix it for my
> > > setup.
> > > 
> > > Currently, the TCK runs will fail anyway as we need to fix java
> > > mail
> > > first but getting the same exception / outcome as JL would be
> > > beneficial as it would prove, that the setup works and others can
> > > simply replicate - if this work, I will re-evaluate the
> > > instructions
> > > for debugging ;)
> > > 
> > > 
> > > Gruß & thanks
> > > Richard
> > > 
> > > 
> > > Am Montag, dem 25.04.2022 um 14:13 -0700 schrieb David Blevins:
> > > > Thanks for digging into this, Richard!
> > > > 
> > > > Agree with your prior statements about updating the README,
> > > > branching
> > > > for TomEE 8 and making TomEE 9 the master branch in the tomee-
> > > > tck
> > > > project.
> > > > 
> > > > 
>

Re: Increasing Discard Old Builds strategy in CI

[Zowalla, Richard]

Hi Cesar,

I have no problem with increasing the values for the discard strategy.
It makes sense to keep it a bit longer for PRs.

However, we need to carefully monitor the disk usage / volume used as
INFRA has a problem if our used storage volume per jobs exceeds a
certain quota. 

We occupied 1,5T last week (cumulated over a few weeks) and they were a
bit mad as the Jenkins CI env went out of storage.

Gruß
Richard


Am Dienstag, dem 26.04.2022 um 11:39 -0600 schrieb Cesar Hernandez:
> Hello,
> 
> Our current Discard old builds Strategy in CI for PR's for the master
> branch is [1]:
> Days to keep builds: 2
> Max # of builds to keep: 3
> 
> Is there any objection if I update this to at least:
> Days to keep builds:  15
> Max # of builds to keep: 30
> 
> Currently, if one opens a PR on a Friday and tries to catch up on
> mid-Monday next week, the PR results are gone.
> The above proposal will also give us a bit more room for more context
> on
> how PR's and past builds have evolved, especially when trying to
> chase and
> resolve random test failures.
> 
> 
> [1]
> https://ci-builds.apache.org/job/Tomee/job/master-pull-request


smime.p7s
Description: S/MIME cryptographic signature

Re: TCK Work - Smoothing the path (was Re: How can I help?)

[Zowalla, Richard]

It looks like the SQL is not the real issue here - although it is a bit
confusing because the select statements look ok to me. 

However, after same additional digging / fiddling arround, I am at a
point, there the JVM for the tests does not startup due to an
StackOverflowError [1].

I tried remote debugging via "-dj" but have no glue why I am running to
this StackOverflowError during the "ant.java(...)" call in the related
groovy command. I bet, that I miss a little detail - so happy to any
additional input ;)

Gruß
R


[1] https://gist.github.com/rzo1/0af90723dc0c6689a6f7d7bae9d2e8da


Am Dienstag, dem 26.04.2022 um 09:59 +0000 schrieb Zowalla, Richard:
> Hi,
> 
> I changed the script pointing to the released ee9.1 tck now and
> updated
> the README accordingly. If the instructions are followed carefully,
> it
> will lead to a fresh installation.
> 
> In the process, I noticed, that Glassfish 6.0.0 isn't available
> anymore
> and is replaced by 6.2.5 - JL mentioned on Slack, that 6.2.5 should
> also work. 
> 
> I think, that we do not really need a public git repository. Setting
> it
> up with the script is really straight forward. However, putting the
> TCK
> installation into a local git repository makes totally sense in order
> to avoid delete / unpack cycles due to the modifications on the
> installation, if the TCK is run.
> 
> I added some instructions in the README.
> 
> Currently, I am struggling with 
> 
> [ERROR] java.sql.SQLSyntaxErrorException: Syntax error: Encountered
> "Simple_Select_Query" at line 1, column 1.
> [INFO] 1130 of 1307 SQL statements executed successfully
> 
> when running
> 
> rm -rf target/ && ./runtests -Dhttps.protocols=TLSv1.1,TLSv1.2 --ee91
> --env -nc -c -U -w tomee-plume
> com.sun.ts.tests.ejb30.lite.appexception.singleton.annotated.Client
> 
> as the initial setup of the derby database seem to fail - don't have
> much ideas but using the search engine of trust I found an entry,
> that
> this also happened on a tck.work build long time ago.
> 
> I guess, that I am just missing a little thing to fix it for my
> setup.
> 
> Currently, the TCK runs will fail anyway as we need to fix java mail
> first but getting the same exception / outcome as JL would be
> beneficial as it would prove, that the setup works and others can
> simply replicate - if this work, I will re-evaluate the instructions
> for debugging ;)
> 
> 
> Gruß & thanks
> Richard
> 
> 
> Am Montag, dem 25.04.2022 um 14:13 -0700 schrieb David Blevins:
> > Thanks for digging into this, Richard!
> > 
> > Agree with your prior statements about updating the README,
> > branching
> > for TomEE 8 and making TomEE 9 the master branch in the tomee-tck
> > project.
> > 
> > 
> > > On Apr 24, 2022, at 11:14 PM, Zowalla, Richard <
> > > richard.zowa...@hs-heilbronn.de> wrote:
> > > 
> > > Ok, I found it:
> > > 
> > > - 
> > > https://lists.apache.org/thread/sfbvz76c527wojym71csv72k8j2qrrg7
> > > 
> > > If we adjust the script to target the (released) ee9.1 tck
> > > (instead
> > > of
> > > the snapshots), it will certainly help. (This was the script I
> > > had
> > > in
> > > mint)
> > 
> > Agree.  Maybe it needs a new name as well so it's more clear that
> > it
> > can be used to create a fresh setup.
> > 
> > > But while searching the list archive, I also found this post on
> > > happy
> > > TCK work:
> > > 
> > > - 
> > > https://lists.apache.org/thread/vgthyd8d7rww2p398r9swx8y37mwxf9c
> > > 
> > > Sadly the setup images from IntelliJ IDEA are gone (maybe you
> > > have
> > > them
> > > somewhere, David?).
> > 
> > Unfortunately, I don't have those images anymore.  We can maybe
> > describe the menu steps instead of showing images.  Getting that on
> > the website in the developer area would be good.  
> > 
> > > Perhaps we should provide a similar jakartaeetck-9.x installation
> > > via a
> > > Git repository?
> > > 
> > > Then we could adjust the "update" script and make it an "install"
> > > script.
> > 
> > The trick here is licensing of the TCK source code, which is
> > EPL.  Here's the source of truth on "is this license ok" questions:
> > 
> >  - 
> > https://www.apache.org/legal/resolved.html#weak-copyleft-licenses
> > 
> > Effectively, we can use EPL in binary form.  In source form it's ok
> > in small amounts where it generally can't be avoided.  An entire
> > repository of EPL source code living under 
> > https://github.com/apache/
> >  is likely not ok.
> > 
> > It doesn't mean the idea is shot, but it does mean that repo would
> > have to live outside the Apache org in github.
> > 
> > > That would ease the necessary setup steps. Wdyt?
> > 
> > Definitely agree it's a great idea.  Perhaps we could create an org
> > of our own?
> > 
> > 
> > -David
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: TCK Work - Smoothing the path (was Re: How can I help?)

[Zowalla, Richard]

Hi,

I changed the script pointing to the released ee9.1 tck now and updated
the README accordingly. If the instructions are followed carefully, it
will lead to a fresh installation.

In the process, I noticed, that Glassfish 6.0.0 isn't available anymore
and is replaced by 6.2.5 - JL mentioned on Slack, that 6.2.5 should
also work. 

I think, that we do not really need a public git repository. Setting it
up with the script is really straight forward. However, putting the TCK
installation into a local git repository makes totally sense in order
to avoid delete / unpack cycles due to the modifications on the
installation, if the TCK is run.

I added some instructions in the README.

Currently, I am struggling with 

[ERROR] java.sql.SQLSyntaxErrorException: Syntax error: Encountered
"Simple_Select_Query" at line 1, column 1.
[INFO] 1130 of 1307 SQL statements executed successfully

when running

rm -rf target/ && ./runtests -Dhttps.protocols=TLSv1.1,TLSv1.2 --ee91
--env -nc -c -U -w tomee-plume
com.sun.ts.tests.ejb30.lite.appexception.singleton.annotated.Client

as the initial setup of the derby database seem to fail - don't have
much ideas but using the search engine of trust I found an entry, that
this also happened on a tck.work build long time ago.

I guess, that I am just missing a little thing to fix it for my setup.

Currently, the TCK runs will fail anyway as we need to fix java mail
first but getting the same exception / outcome as JL would be
beneficial as it would prove, that the setup works and others can
simply replicate - if this work, I will re-evaluate the instructions
for debugging ;)


Gruß & thanks
Richard


Am Montag, dem 25.04.2022 um 14:13 -0700 schrieb David Blevins:
> Thanks for digging into this, Richard!
> 
> Agree with your prior statements about updating the README, branching
> for TomEE 8 and making TomEE 9 the master branch in the tomee-tck
> project.
> 
> 
> > On Apr 24, 2022, at 11:14 PM, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > Ok, I found it:
> > 
> > - https://lists.apache.org/thread/sfbvz76c527wojym71csv72k8j2qrrg7
> > 
> > If we adjust the script to target the (released) ee9.1 tck (instead
> > of
> > the snapshots), it will certainly help. (This was the script I had
> > in
> > mint)
> 
> Agree.  Maybe it needs a new name as well so it's more clear that it
> can be used to create a fresh setup.
> 
> > But while searching the list archive, I also found this post on
> > happy
> > TCK work:
> > 
> > - https://lists.apache.org/thread/vgthyd8d7rww2p398r9swx8y37mwxf9c
> > 
> > Sadly the setup images from IntelliJ IDEA are gone (maybe you have
> > them
> > somewhere, David?).
> 
> Unfortunately, I don't have those images anymore.  We can maybe
> describe the menu steps instead of showing images.  Getting that on
> the website in the developer area would be good.  
> 
> > Perhaps we should provide a similar jakartaeetck-9.x installation
> > via a
> > Git repository?
> > 
> > Then we could adjust the "update" script and make it an "install"
> > script.
> 
> The trick here is licensing of the TCK source code, which is
> EPL.  Here's the source of truth on "is this license ok" questions:
> 
>  - https://www.apache.org/legal/resolved.html#weak-copyleft-licenses
> 
> Effectively, we can use EPL in binary form.  In source form it's ok
> in small amounts where it generally can't be avoided.  An entire
> repository of EPL source code living under https://github.com/apache/
>  is likely not ok.
> 
> It doesn't mean the idea is shot, but it does mean that repo would
> have to live outside the Apache org in github.
> 
> > That would ease the necessary setup steps. Wdyt?
> 
> Definitely agree it's a great idea.  Perhaps we could create an org
> of our own?
> 
> 
> -David
> 


smime.p7s
Description: S/MIME cryptographic signature

Dependabot PRs' flooding

[Zowalla, Richard]

Hi,

a few weeks ago, I noticed, that a lot of mails are generated by
@dependabot on the TomEE repositories.

It contains a lot of false positives (i.e. in the examples) and often
requires additional efforts (i.e. code changes, xml adjustments) to
upgrade.

We are updating the dependencies before releases anyway (if they are
important), so I am wondering, if we should disable @dependabot for the
TomEE repositories?

According to INFRA, it is possible to disable via 
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-DependabotAlertsandUpdates

Any thoughts? ;)

Richard


smime.p7s
Description: S/MIME cryptographic signature

Re: TCK Work - Smoothing the path (was Re: How can I help?)

[Zowalla, Richard]

Ok, I found it:

- https://lists.apache.org/thread/sfbvz76c527wojym71csv72k8j2qrrg7

If we adjust the script to target the (released) ee9.1 tck (instead of
the snapshots), it will certainly help. (This was the script I had in
mint)

But while searching the list archive, I also found this post on happy
TCK work:

- https://lists.apache.org/thread/vgthyd8d7rww2p398r9swx8y37mwxf9c

Sadly the setup images from IntelliJ IDEA are gone (maybe you have them
somewhere, David?).

Perhaps we should provide a similar jakartaeetck-9.x installation via a
Git repository?

Then we could adjust the "update" script and make it an "install"
script. 

That would ease the necessary setup steps. Wdyt?

Gruß
Richard


Am Montag, dem 25.04.2022 um 05:54 +0000 schrieb Zowalla, Richard:
> > > The trick is that setup is difficult to maintain and can be quite
> > > intimidating.
> 
> I can remember ;) - my first attempts in May 21 were indeed
> intimidating.
> 
> > Richard, have you tried to run any tests yet?  If not, are you
> > possibly willing to be the brave guy who tries it first, hits the
> > issues and works with myself or Jean-Louis to smooth the path for
> > Zoltán and others?
> 
> Not for the current M8 Snapshot yet. Last time I did run (some) tests
> of the ee9 tck was in May 21 - my tech stack switched, so I have to
> set
> it up from scratch again. 
> 
> There can be no better environment to try and hit the (setup) issues
> -
> so yes, count me in ;)
> 
> As far as I can remember, the README also needs an overhaul and we
> should include the handy script, which does some of the setup
> automatically. I think, that David posted it on the list.
> 
> I think, that we also need to switch to a dedicated tomee-8.x branch
> and move the tomee-9.x branch to master in the tomee-tck harness
> repo.
> 
> Gruß
> Richard
> 
> Am Sonntag, dem 24.04.2022 um 13:47 -0700 schrieb David Blevins:
> > If we could get a few more people familiar with running the Jakarta
> > EE TCK in TomEE and ready to start fixing test failures, that'd be
> > the biggest impact on all our current and future certification
> > efforts.
> > 
> > The trick is that setup is difficult to maintain and can be quite
> > intimidating.
> > 
> > Richard, have you tried to run any tests yet?  If not, are you
> > possibly willing to be the brave guy who tries it first, hits the
> > issues and works with myself or Jean-Louis to smooth the path for
> > Zoltán and others?
> > 
> > Truthfully, it's something we should be doing before every release
> > on
> > any branch.  It's another particularly large release process gap we
> > do need to eventually fill.
> > 
> > 
> > -David
> > 
> > 
> > > On Apr 24, 2022, at 2:06 AM, Zowalla, Richard <
> > > richard.zowa...@hs-heilbronn.de> wrote:
> > > 
> > > Hi Zoltán,
> > > 
> > > It's very great from you and it's truly awesome when a long time
> > > user
> > > of TomEE decides to contribute :)
> > > 
> > > First of all, do not get intimidated by your first ticket. If it
> > > ends
> > > up being too hard or just not fun, let's find something else for
> > > you.
> > > There is always plenty of work to do.
> > > 
> > > We are currently working on TomEE 9. Therefore, we moved away
> > > from
> > > our
> > > previous byte code transformation approach and switched TomEE
> > > master to
> > > TomEE 9 (Jakarta). 
> > > 
> > > While we made good progress, there is still a lot todo. The
> > > efforts
> > > and
> > > open tasks are tracked in [1]. A lot of effort is currently done
> > > to
> > > switch the MicroProfile impl to MP Smallrye impls in order to
> > > move
> > > to
> > > the jakarta namespace [2].
> > > 
> > > If you are interested in contributing to our TomEE 9 efforts, we
> > > can
> > > surely find some beginner friendly tasks in this area.
> > > 
> > > Gruß
> > > Richard
> > > 
> > > 
> > > [1] https://issues.apache.org/jira/browse/TOMEE-3862
> > > [2] 
> > > https://lists.apache.org/thread/hdntdhwqkr91o2mszojq66qcfzszw96p
> > > 
> > > 
> > > Am Samstag, dem 23.04.2022 um 20:21 +0200 schrieb Zoltán Tichov:
> > > > Hi!
> > > > 
> > > > I live in Hungary. I am working at an IT company as a software
> > > > developer, I
> > > > develop java
> > > > webapps with jsf (PrimeFaces) 

TCK Work - Smoothing the path (was Re: How can I help?)

[Zowalla, Richard]

> 
> > The trick is that setup is difficult to maintain and can be quite
> > intimidating.

I can remember ;) - my first attempts in May 21 were indeed
intimidating.

> Richard, have you tried to run any tests yet?  If not, are you
> possibly willing to be the brave guy who tries it first, hits the
> issues and works with myself or Jean-Louis to smooth the path for
> Zoltán and others?

Not for the current M8 Snapshot yet. Last time I did run (some) tests
of the ee9 tck was in May 21 - my tech stack switched, so I have to set
it up from scratch again. 

There can be no better environment to try and hit the (setup) issues -
so yes, count me in ;)

As far as I can remember, the README also needs an overhaul and we
should include the handy script, which does some of the setup
automatically. I think, that David posted it on the list.

I think, that we also need to switch to a dedicated tomee-8.x branch
and move the tomee-9.x branch to master in the tomee-tck harness repo.

Gruß
Richard

Am Sonntag, dem 24.04.2022 um 13:47 -0700 schrieb David Blevins:
> If we could get a few more people familiar with running the Jakarta
> EE TCK in TomEE and ready to start fixing test failures, that'd be
> the biggest impact on all our current and future certification
> efforts.
> 
> The trick is that setup is difficult to maintain and can be quite
> intimidating.
> 
> Richard, have you tried to run any tests yet?  If not, are you
> possibly willing to be the brave guy who tries it first, hits the
> issues and works with myself or Jean-Louis to smooth the path for
> Zoltán and others?
> 
> Truthfully, it's something we should be doing before every release on
> any branch.  It's another particularly large release process gap we
> do need to eventually fill.
> 
> 
> -David
> 
> 
> > On Apr 24, 2022, at 2:06 AM, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > Hi Zoltán,
> > 
> > It's very great from you and it's truly awesome when a long time
> > user
> > of TomEE decides to contribute :)
> > 
> > First of all, do not get intimidated by your first ticket. If it
> > ends
> > up being too hard or just not fun, let's find something else for
> > you.
> > There is always plenty of work to do.
> > 
> > We are currently working on TomEE 9. Therefore, we moved away from
> > our
> > previous byte code transformation approach and switched TomEE
> > master to
> > TomEE 9 (Jakarta). 
> > 
> > While we made good progress, there is still a lot todo. The efforts
> > and
> > open tasks are tracked in [1]. A lot of effort is currently done to
> > switch the MicroProfile impl to MP Smallrye impls in order to move
> > to
> > the jakarta namespace [2].
> > 
> > If you are interested in contributing to our TomEE 9 efforts, we
> > can
> > surely find some beginner friendly tasks in this area.
> > 
> > Gruß
> > Richard
> > 
> > 
> > [1] https://issues.apache.org/jira/browse/TOMEE-3862
> > [2] 
> > https://lists.apache.org/thread/hdntdhwqkr91o2mszojq66qcfzszw96p
> > 
> > 
> > Am Samstag, dem 23.04.2022 um 20:21 +0200 schrieb Zoltán Tichov:
> > > Hi!
> > > 
> > > I live in Hungary. I am working at an IT company as a software
> > > developer, I
> > > develop java
> > > webapps with jsf (PrimeFaces) and microservice like apps without
> > > any
> > > container technology
> > > and Oracle database.
> > > 
> > > We want to switch to jakarta ee 9 at the company, but
> > > unfortunately
> > > we ran
> > > into problems with tomee 9 and I would like to contribute to
> > > fixing
> > > these
> > > bugs and possibly improving tomee jakarta 10. (I'm sorry to read
> > > on
> > > another
> > > tomee mailing list, that you had to skip jakarta ee 8 and 9
> > > compliance
> > > entirely)
> > > I use java 11 and netbeans on windows 10. If we don't have to, we
> > > don't
> > > want to use another app server because we've been using tomee
> > > since
> > > 1.7.3.
> > > 
> > > Best regards: Zoltán Tichov


smime.p7s
Description: S/MIME cryptographic signature

Re: How can I help?

[Zowalla, Richard]

Hi Zoltán,
 
It's very great from you and it's truly awesome when a long time user
of TomEE decides to contribute :)

First of all, do not get intimidated by your first ticket. If it ends
up being too hard or just not fun, let's find something else for you.
There is always plenty of work to do.

We are currently working on TomEE 9. Therefore, we moved away from our
previous byte code transformation approach and switched TomEE master to
TomEE 9 (Jakarta). 

While we made good progress, there is still a lot todo. The efforts and
open tasks are tracked in [1]. A lot of effort is currently done to
switch the MicroProfile impl to MP Smallrye impls in order to move to
the jakarta namespace [2].

If you are interested in contributing to our TomEE 9 efforts, we can
surely find some beginner friendly tasks in this area.

Gruß
Richard


[1] https://issues.apache.org/jira/browse/TOMEE-3862
[2] https://lists.apache.org/thread/hdntdhwqkr91o2mszojq66qcfzszw96p


Am Samstag, dem 23.04.2022 um 20:21 +0200 schrieb Zoltán Tichov:
> Hi!
> 
> I live in Hungary. I am working at an IT company as a software
> developer, I
> develop java
> webapps with jsf (PrimeFaces) and microservice like apps without any
> container technology
> and Oracle database.
> 
> We want to switch to jakarta ee 9 at the company, but unfortunately
> we ran
> into problems with tomee 9 and I would like to contribute to fixing
> these
> bugs and possibly improving tomee jakarta 10. (I'm sorry to read on
> another
> tomee mailing list, that you had to skip jakarta ee 8 and 9
> compliance
> entirely)
> I use java 11 and netbeans on windows 10. If we don't have to, we
> don't
> want to use another app server because we've been using tomee since
> 1.7.3.
> 
> Best regards: Zoltán Tichov

AW: Next TomEE+ 7.1.x release

[Zowalla, Richard]

Hi,

did some fixes and now the 7.1.x full build is back to green: 
https://ci-builds.apache.org/job/Tomee/job/tomee-7.1.x/11/

That means we are in good shape for the dependency updates as we now have a 
valid baseline and any change can be validated via CI.

Gruß
Richard

Von: Geeth Narayanan 
Gesendet: Freitag, 22. April 2022 14:47:27
An: dev@tomee.apache.org
Betreff: Re: Next TomEE+ 7.1.x release

Thanks, Richard and Jean-Louis. Appreciate your flexibility.

Let me start on the workflow items and then look at the dependencies to see
what's included and maybe go out the latest minor version in that mainline
version.

Will keep you posted.

On Fri, Apr 22, 2022 at 4:18 AM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Hi,
>
> Thanks Richard for restoring a CI for the 7.1.x branch.
>
> If we can have multiple PRs to update the dependencies and the build is
> green, I agree with Richard, it should not be a big problem to do the
> release.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Fri, Apr 22, 2022 at 8:02 AM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
>
> > Hi Geeth,
> >
> > thanks for your first contribution to TomEE. It is very much
> > appreciated.
> >
> > The last release was in 2020 and most effort has been shifted to 8.x
> > and 9.x. Personally, I do not use 7.1.x in any project anymore.
> > Therefore, I am unable to test related binaries.
> >
> > Nevertheless, I appreciate your attitude in offering help in reviewing
> > / contributing. Therefore, I created / restored the CI environment for
> > 7.1.x [1] and triggered a full build, so we get some information how
> > the current build looks like.
> >
> > With a working CI env in place, we would need to conduct (or at least
> > try) some dependency updates (like Tomcat, BatchEE (maybe?), CXF
> > (maybe?), Johnzon (maybe?), OWB (maybe?), ActiveMQ (maybe?), MyFaces
> > (maybe?), Mojarra (maybe?), Jackson (maybe - used in Microprofile),
> > etc.) and find the latest corresponding versions supporting EE7.
> >
> > Perhaps that would be a good starting point to contribute, if you have
> > some spare time / resources available.
> >
> > Our basic contribution workflow would be:
> >
> > (1) Create a Jira (e.g. for a version update)
> > (2) Ask on the dev@ list to be assigned
> > (3) Work on the issue. Ask for help / guidance if needed
> > (4) Create a PR.
> > (5) Ask for review on dev@
> >
> > In addition it needs some fixes on the structure of the project itself
> > (SCM urls as git-wip-us went EOL a few weeks ago). If we decide to
> > pursue this further, I can do these (structural) changes.
> >
> > If the CI is green afterwards, a potential 7.1.5 would be in a good
> > shape IMHO.
> >
> > The (mechanical) work to conduct a release isn't that much of an effort
> > but requires a TomEE PMC member for some of the steps (eg. the vote,
> > etc.).
> >
> > The list of currently resolved issues for a 7.1.5 is here: [2]
> >
> > Gruß
> > Richard
> >
> >
> > [1] https://ci-builds.apache.org/job/Tomee/job/tomee-7.1.x/
> > [2] https://issues.apache.org/jira/projects/TOMEE/versions/12349482
> >
> > Am Donnerstag, dem 21.04.2022 um 19:29 -0500 schrieb Geeth Narayanan:
> > > Hi,
> > >
> > > I recently made my first code contribution as a patch to 7.1.x
> > > release.
> > > This was for a startup issue that has been fixed in 8.x. It was also
> > > not
> > > present in 7.1.1, but was introduced in 7.1.2.
> > >
> > > I understand that the team's focus is to release 8.x and 9.x, but I
> > > was
> > > wondering if you could put out 7.1.5 with this change and anything
> > > else in
> > > there. Looks like it's been a while since 7.1.4 was released.
> > >
> > > As I mentioned, it was my first foray into contribution, so please
> > > let me
> > > know if I can help in any way like reviewing binaries or contributing
> > > on
> > > anything else.
> > >
> > > Appreciate the help!
> > >
> > > More information on the issue:
> > >
> > > https://issues.apache.org/jira/browse/TOMEE-2919
> > > https://issues.apache.org/jira/browse/OPENEJB-2145
> > >
> > > Here is the patch:
> > >
> > > TOMEE-2919 : Fix for ConcurrentModificationException error deploying
> > > … by
> > > gnarayan1 · Pull Request #868 · apache/tomee · GitHub
> > > <https://github.com/apache/tomee/pull/868>
> > >
> > > Thanks.
> > >
> > > Geeth
> >
>

Re: Re: Follow-up to 8.0.11: Update of release documentation

[Zowalla, Richard]

Hi Rod,

I updated the release tools (with TOMEE-3921), so we are now creating
consistent hashes regardless of the tooling used (homebrew release
tools vs linux onboard), i.e. it will be " filename".

Gruß
Richard

Am Freitag, dem 22.04.2022 um 21:41 + schrieb Jenkins, Rodney J
(Rod):
> <<
> Do you have a preference for automation in your environment and
> for
> docker?
> 
> My only preference is consistency.  I have no technical preference
> one way or the other.  I can script it either way.  I do not want to
> alter Dockerfiles each time we do a release.
> 
> Thanks,
> Rod.
> 
> 
> On 4/22/22, 11:32 AM, "Richard Zowalla"  wrote:
> 
> Nationwide Information Security Warning: This is an EXTERNAL
> email. Use CAUTION before clicking on links, opening attachments, or
> responding. (Sender: 
> dev-return-29302-JENKIR14=nationwide@tomee.apache.org)
> 
> -
> -
> 
> 
> Hi Rod
> 
> > My counterparts have reported that the sha files are in
> different 
> > format than the last version, but the same as 8.0.7. 
> 
> >It would be nice if we could have a permanent standard.   When
> we
> >change the formats, it breaks automation on our end and in the
> docker
> >images.
> 
> I agree - this time, the SHA512 hashes are created using our 
> https://github.com/apache/tomee-release-tools 
> 
> I quickly checked the other releases (1.7.x, 7.x, 7.1.x), which
> follow
> the same pattern.
> 
> BUT I agree, that it was different in previous TomEE 8 releases -
> perhaps the SHA512 hashes were not created using the tomee-
> release-
> tools. Nevertheless, we can enhance the release tools to follow
> the
> unix like pattern:
> 
>  filename
> 
> instead of
> 
> 
> 
> I have no preference ;) - for the first option, we need to update
> the
> release tools to include the filename to the .sha512 files. That
> would
> beconsistent in case the release hashs aren't created via the
> tomee-
> release-tools.
> 
> Do you have a preference for automation in your environment and
> for
> docker?
> 
> Gruß 
> Rchard
> 
> 
> 
> 
> Am Freitag, dem 22.04.2022 um 15:26 + schrieb Jenkins, Rodney
> J
> (Rod):
> > Richard,
> > 
> > Thank you for the release and congrats on your 1st release.
> > 
> > My counterparts have reported that the sha files are in
> different
> > format than the last version, but the same as 8.0.7.
> > 
> > It would be nice if we could have a permanent standard.   When
> we
> > change the formats, it breaks automation on our end and in the
> docker
> > images.
> > 
> > I've not had the time to verify this for myself, I will get to
> that
> > in the next couple of days.
> > 
> > Thank you,
> > Rod.
> > 
> > From: Zowalla, Richard 
> > Sent: Friday, April 22, 2022 1:37 AM
> > To: dev@tomee.apache.org 
> > Subject: [EXTERNAL] Follow-up to 8.0.11: Update of release
> > documentation
> > 
> > Hi all,
> > 
> > after conducting my first release, I put my notes together and
> > updated
> > our release documentation:
> > https://tomee.apache.org/dev/release-tomee.html
> > 
> > It might not be complete and might require some further
> polishing but
> > I
> > think, that this will help others in conducting a release. The
> > initial
> > ASF-related setup + GPG keys requires some effort ;)
> > 
> > In general, we learned that teaming up (committer + pmc) for a
> > release
> > works quite well and it was a pleassure to work with JL on
> 8.0.11 :)
> > 
> > Most of the mechanical steps can be conducted with committer
> access
> > privileges (building, tagging, nexus/maven deploy, staging
> artifacts
> > to
> > dist/dev); some formal steps like open/close the VOTE, moving
> the
> > artifacts from dist/dev to dist/release require a PMC member to
> be
> > involved.
> > 
> > Gruß
> > Richard
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Re: [ANN] Apache TomEE 8.0.11

[Zowalla, Richard]

Hi,

added some comments regarding the "uid" used in the comment.
The rest looks good to me. Thanks for preparing!

Gruß
Richard


Am Freitag, dem 22.04.2022 um 22:13 + schrieb Jenkins, Rodney J
(Rod):
> Richard,
> 
> I added your key to the Docker files.  Can you please verify your
> information here:
> 
> https://github.com/tomitribe/docker-tomee/pull/65/files
> 
> 
> Also, if someone would review the changes, I would appreciate it.  If
> it is not approved on Monday, I will merge.
> 
> Thank you,
> Rod.
> 
> 
> On 4/22/22, 11:32 AM, "Richard Zowalla"  wrote:
> 
> Nationwide Information Security Warning: This is an EXTERNAL
> email. Use CAUTION before clicking on links, opening attachments, or
> responding. (Sender: 
> dev-return-29303-JENKIR14=nationwide@tomee.apache.org)
> 
> -
> -
> 
> 
> Thanks, Rod!
> 
> Am Freitag, dem 22.04.2022 um 15:21 + schrieb Jenkins, Rodney
> J
> (Rod):
> > I will get started on the Docker images.
> > 
> > Thank you,
> > Rod.
> > 
> > From: Richard Zowalla 
> > Sent: Friday, April 22, 2022 5:00:58 AM
> > To: dev@tomee.apache.org ; 
> > us...@tomee.apache.org ; 
> annou...@apache.org
> > 
> > Subject: [EXTERNAL] [ANN] Apache TomEE 8.0.11
> > 
> > Nationwide Information Security Warning: This is an EXTERNAL
> email.
> > Use CAUTION before clicking on links, opening attachments, or
> > responding. (Sender: 
> > users-return-28024-JENKIR14=nationwide@tomee.apache.org)
> > 
> > -
> --
> > ---
> > 
> > 
> > The Apache TomEE team is pleased to announce the availability
> of
> > TomEE
> > 8.0.11
> > 
> > Apache TomEE delivers enterprise application containers and
> services
> > based on, but not limited to the Enterprise JavaBeans
> Specification
> > and
> > Java Enterprise Edition Specifications.
> > 
> > These releases primarily provide bug fixes, documentation and
> update
> > the dependencies TomEE uses.
> > 
> > Full release notes:
> > 
> > - https://tomee.apache.org/8.0.11/release-notes.html
> > -
> > 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12351352
> > 
> > Downloads are available at: 
> https://tomee.apache.org/download.html
> > 
> > - The Apache TomEE team
> > 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Follow-up to 8.0.11: Update of release documentation

[Zowalla, Richard]

Hi all,

after conducting my first release, I put my notes together and updated
our release documentation: 
https://tomee.apache.org/dev/release-tomee.html

It might not be complete and might require some further polishing but I
think, that this will help others in conducting a release. The initial
ASF-related setup + GPG keys requires some effort ;)

In general, we learned that teaming up (committer + pmc) for a release
works quite well and it was a pleassure to work with JL on 8.0.11 :)

Most of the mechanical steps can be conducted with committer access
privileges (building, tagging, nexus/maven deploy, staging artifacts to
dist/dev); some formal steps like open/close the VOTE, moving the
artifacts from dist/dev to dist/release require a PMC member to be
involved. 

Gruß
Richard


smime.p7s
Description: S/MIME cryptographic signature

Re: Next TomEE+ 7.1.x release

[Zowalla, Richard]

Hi Geeth,

thanks for your first contribution to TomEE. It is very much
appreciated.

The last release was in 2020 and most effort has been shifted to 8.x
and 9.x. Personally, I do not use 7.1.x in any project anymore.
Therefore, I am unable to test related binaries.

Nevertheless, I appreciate your attitude in offering help in reviewing
/ contributing. Therefore, I created / restored the CI environment for
7.1.x [1] and triggered a full build, so we get some information how
the current build looks like.

With a working CI env in place, we would need to conduct (or at least
try) some dependency updates (like Tomcat, BatchEE (maybe?), CXF
(maybe?), Johnzon (maybe?), OWB (maybe?), ActiveMQ (maybe?), MyFaces
(maybe?), Mojarra (maybe?), Jackson (maybe - used in Microprofile),
etc.) and find the latest corresponding versions supporting EE7.

Perhaps that would be a good starting point to contribute, if you have
some spare time / resources available. 

Our basic contribution workflow would be:

(1) Create a Jira (e.g. for a version update)
(2) Ask on the dev@ list to be assigned
(3) Work on the issue. Ask for help / guidance if needed
(4) Create a PR. 
(5) Ask for review on dev@

In addition it needs some fixes on the structure of the project itself
(SCM urls as git-wip-us went EOL a few weeks ago). If we decide to
pursue this further, I can do these (structural) changes.

If the CI is green afterwards, a potential 7.1.5 would be in a good
shape IMHO. 

The (mechanical) work to conduct a release isn't that much of an effort
but requires a TomEE PMC member for some of the steps (eg. the vote,
etc.).

The list of currently resolved issues for a 7.1.5 is here: [2]

Gruß
Richard


[1] https://ci-builds.apache.org/job/Tomee/job/tomee-7.1.x/
[2] https://issues.apache.org/jira/projects/TOMEE/versions/12349482

Am Donnerstag, dem 21.04.2022 um 19:29 -0500 schrieb Geeth Narayanan:
> Hi,
> 
> I recently made my first code contribution as a patch to 7.1.x
> release.
> This was for a startup issue that has been fixed in 8.x. It was also
> not
> present in 7.1.1, but was introduced in 7.1.2.
> 
> I understand that the team's focus is to release 8.x and 9.x, but I
> was
> wondering if you could put out 7.1.5 with this change and anything
> else in
> there. Looks like it's been a while since 7.1.4 was released.
> 
> As I mentioned, it was my first foray into contribution, so please
> let me
> know if I can help in any way like reviewing binaries or contributing
> on
> anything else.
> 
> Appreciate the help!
> 
> More information on the issue:
> 
> https://issues.apache.org/jira/browse/TOMEE-2919
> https://issues.apache.org/jira/browse/OPENEJB-2145
> 
> Here is the patch:
> 
> TOMEE-2919 : Fix for ConcurrentModificationException error deploying
> … by
> gnarayan1 · Pull Request #868 · apache/tomee · GitHub
> 
> 
> Thanks.
> 
> Geeth


smime.p7s
Description: S/MIME cryptographic signature

Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache

[Zowalla, Richard]

Comments are still pending? Didn't see any?

+1 for don't maintain it in two different places + David's idea.

Gruß
Richard

Am Dienstag, dem 19.04.2022 um 14:33 -0700 schrieb David Blevins:
> Those pages looking great!  Left some specific comments in the PR.
> 
> > On Apr 17, 2022, at 12:10 PM, Swell 
> > wrote:
> > 
> > Thank you all for your feedbacks, comparison pages sent for review:
> > + https://github.com/apache/tomee/pull/854
> > + https://github.com/apache/tomee/pull/855
> 
> Thanks for tracking down all that version information!  That's always
> a lot of tedious digging.
> 
> > you might want those two "per-version" comparison pages to be
> > without the
> > tables for "flavors" and "implementations" since these tables also
> > are in
> > the "main" comparison page in the website PR:
> 
> I agree we definitely don't want it in two places.  In my experience
> documentation doesn't get maintained well, so anything duplicated
> usually ends up drifting apart and causing confusion.
> 
> My vote would be to kill the implementation information from the main
> comparison and leave that information only in the comparison pages
> dedicated to their specific version.
> 
> 
> -David
> 
> 
> > On Tue, 12 Apr 2022 at 21:04, David Blevins <
> > david.blev...@gmail.com> wrote:
> > 
> > > Sounds awesome, everyone.
> > > 
> > > Total side note.  I cannot express how much I love seeing this
> > > much
> > > engagement and collaboration.  Often times PRs don't get any
> > > feedback at
> > > all and sit for months.  It's really fantastic to see activity
> > > like this.
> > > 
> > > 
> > > -David
> > > 
> > > 
> > > > On Apr 12, 2022, at 11:29 AM, Swell 
> > > > wrote:
> > > > 
> > > > This reflects my first attempts, i still have them "per-
> > > > version"
> > > > uncommited, already linking to specs by precise version
> > > > 
> > > > so it wont be too hard for me to turn around, and give you
> > > > these
> > > versions.
> > > > the drawback is these pages may have to be maintained on
> > > > dependencies
> > > > updates and releases, but that may be ok and clearer for users
> > > > visiting
> > > the
> > > > website.
> > > > 
> > > > i'll send the per version to "tomee" repo first then the page
> > > > for website
> > > > repo
> > > > 
> > > > On Tue, 12 Apr 2022 at 20:09, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> wrote:
> > > > 
> > > > > Makes sense, imho. Thanks for the thoughts, David.
> > > > > That would simplify it for the reader.
> > > > > 
> > > > > If we have it per version and link the per version documents
> > > > > from the
> > > > > overall comparision, we are proabably in a good shape.
> > > > > 
> > > > > 
> > > > > 
> > > > > Am Dienstag, dem 12.04.2022 um 10:58 -0700 schrieb David
> > > > > Blevins:
> > > > > > Hey All,
> > > > > > 
> > > > > > I see there's a big thread on PR#37.
> > > > > > 
> > > > > > - https://github.com/apache/tomee-site-generator/pull/37
> > > > > > 
> > > > > > My gut reaction is that we might be trying to achieve the
> > > > > > impossible
> > > > > > by trying to fit every TomEE version and every Java
> > > > > > EE/Jakarta EE
> > > > > > version into one massive matrix or page.
> > > > > > 
> > > > > > What do people think about potentially pausing that, taking
> > > > > > a step
> > > > > > back and seeing if there's a simpler approach.  Often when
> > > > > > I'm
> > > > > > working on code and I notice it's getting just too big and
> > > > > > hard to
> > > > > > fit in my head or on the page in a way that makes sense, I
> > > > > > change my
> > > > > > approach.  Instead of trying to solve the whole problem at
> > > > > > once, I
> > > > > > just take a slice of it that I know I'll need and work on
> > > > > > it till
> > > > > &

Re: TomEE Patch Plugin - Release?

[Zowalla, Richard]

Alright - I will prepare the artifacts. Thanks!

Am Samstag, dem 16.04.2022 um 23:03 +0200 schrieb Jean-Louis Monteiro:
> Of course. Go ahead.
> 
> Le sam. 16 avr. 2022 à 07:14, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> 
> > Hi all,
> > 
> > I included a fix for TOMEE-3903, so we can configure, if created
> > *.tar.gz files are attached to the build or not.
> > 
> > Before that, we attached the *.tar.gz files multiple times, which
> > leads
> > to unexpected behaviour in new Maven versions, e.g. deploying
> > *.tar.gz
> > files as jars (see the first attempt for 8.0.11 release) overriding
> > existing jars, skipping *.tar.gz files from being deployed at all,
> > etc.
> > 
> > So it would be need, if we could do a release of the TomEE patch
> > plugin?
> > 
> > Gruß
> > Richard
> > 


smime.p7s
Description: S/MIME cryptographic signature

TomEE Patch Plugin - Release?

[Zowalla, Richard]

Hi all,

I included a fix for TOMEE-3903, so we can configure, if created
*.tar.gz files are attached to the build or not.

Before that, we attached the *.tar.gz files multiple times, which leads
to unexpected behaviour in new Maven versions, e.g. deploying *.tar.gz
files as jars (see the first attempt for 8.0.11 release) overriding
existing jars, skipping *.tar.gz files from being deployed at all, etc.

So it would be need, if we could do a release of the TomEE patch
plugin?

Gruß
Richard

Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache

[Zowalla, Richard]

Makes sense, imho. Thanks for the thoughts, David.
That would simplify it for the reader. 

If we have it per version and link the per version documents from the
overall comparision, we are proabably in a good shape.



Am Dienstag, dem 12.04.2022 um 10:58 -0700 schrieb David Blevins:
> Hey All,
> 
> I see there's a big thread on PR#37.
> 
>  - https://github.com/apache/tomee-site-generator/pull/37
> 
> My gut reaction is that we might be trying to achieve the impossible
> by trying to fit every TomEE version and every Java EE/Jakarta EE
> version into one massive matrix or page.
> 
> What do people think about potentially pausing that, taking a step
> back and seeing if there's a simpler approach.  Often when I'm
> working on code and I notice it's getting just too big and hard to
> fit in my head or on the page in a way that makes sense, I change my
> approach.  Instead of trying to solve the whole problem at once, I
> just take a slice of it that I know I'll need and work on it till
> it's clean.  Then I move on and take another small slice and
> repeat.  As I keep going I often find there is no more big mess, not
> because I found a better way to do it, but because I never needed it.
> 
> My advice would be to give this a try.  Pause the big PR#37 and shift
> gears.  Instead try nailing just a basic comparison page for TomEE 9
> that is like the one that's there, but adds the spec versions, links
> to the spec documents  and the java information.
> 
> I.e. we copy this page
> 
>  - 
> https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/comparison.adoc
> 
> To here:
> 
>  - 
> https://github.com/apache/tomee/commits/master/docs/comparison.adoc
> 
> Then we start with adding the spec versions and the spec links and
> get that merged.  Afterwards we try adding the java information, and
> get that merged.  Once we have a page we all like, we move on and do
> the same for TomEE 8.0
> 
>  - 
> https://github.com/apache/tomee/blob/tomee-8.x/docs/comparison.adoc
> 
> If we have the energy, let's do 7.1 and 7.0 since we're still
> releasing those once in a while.
> 
> Each page will be of course only mentioning the specifications they
> implement.  We can even use the exact spec names as they existed, so
> for example, all the TomEE 7.0 stuff would say "Java EE" not "Jakarta
> EE" and use "Enterprise JavaBeans" not "Jakarta EnterpriseBeans",
> etc.
> 
> Once we get individual pages for each TomEE version, we will likely
> have a different perspective on what we need for the main comparison
> page.  Possibly we'll need very little as the individual pages will
> be doing most the hard work.
> 
> 
> Thoughts?
> 
> 
> -David
> 
> > On Apr 5, 2022, at 5:42 AM, Swell  wrote:
> > 
> > Thanks Richard,
> > 
> > two pages can be pre-reviewed :
> > • compare-jakarta-versions.html
> > • comparison.html
> > i believe we can choose only one of the two for release. which one
> > do you find more readable ?
> > (they differ in the detailed list of jakarta specs.)
> > 
> > i'll try to update my page later to better reflect JRE ranges and
> > your warnings on JRE/ASM.
> > i have reflected JL work regarding MicroProfile dependencies in my
> > draft PR.
> > 
> > 
> > also we could update TomEE 8.x to MicroProfile 4.1,
> > (SmallRye?) but is it worth ?
> > 
> > Swell
> > 
> > On Tue, 5 Apr 2022 at 11:49, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > Hi Swell,
> > 
> > > my TomEE 8.x is working on both JDK 11 and 17 with a small app.
> > > What 
> > features can be broken with wrong JDK/ASM version ?
> > 
> > (1) If you are running with an unsupported version of ASM the
> > server
> > might not startup or the deployment of applications will simply not
> > work. Most of often this will result in an exception (rather early)
> > telling you, that ASM does not support this specific version of
> > Java.
> > 
> > (2) Our scripts are rather defensively written, but you might
> > encounter
> > issues with unsupported JVM flags (between major JDK versions) or
> > certain other mechanisms do not work (i.e. usages of Unsafe,
> > Illegal
> > Reflective Access, etc.)
> > 
> > Most often this happens with "too new" JDKs (i.e. JDK 18-GA) as we
> > need
> > some time to adjust / test or wait for transient libs to be updated
> > (matter of resources).
> > 
> > > TomEE works on both JDK and JRE, but can use more memory/cache in
> > JDK. 

Re: Time for a TomEE 8.0.11 maintenance release?

[Zowalla, Richard]

As a short update: JL and myself discussed the idea by David from [1]
via Slack. We will try out the 4-eye approach in order to share
knowledge of doing releases for TomEE.

I will take some notes during the process to put it back into up 2 date
release documentation.

Gruß
Richard

Am Dienstag, dem 12.04.2022 um 09:33 + schrieb Zowalla, Richard:
> +1
> 
> Question: We once talked about sharing knowledge about doing releases
> [1], so I am wondering, if we should use 8.0.11 as a pilot test for
> this approach?
> 
> For reference changes currently targeted for 8.0.11 (from Jira)
> attached below.
> 
> Gruß 
> Richard
> 
> [1] https://lists.apache.org/thread/dj0s8lldxlkqnfy43hwnclzwbgv40xht
> 
> 
> == Dependency upgrade
> 
> [.compact]
>  - link:https://issues.apache.org/jira/browse/TOMEE-3872[TOMEE-3872]
> Hibernate Integration 5.6.7
>  - link:https://issues.apache.org/jira/browse/TOMEE-3858[TOMEE-3858]
> OpenJPA 3.2.2
>  - link:https://issues.apache.org/jira/browse/TOMEE-3841[TOMEE-3841]
> SLF4J 1.7.36
>  - link:https://issues.apache.org/jira/browse/TOMEE-3845[TOMEE-3845]
> Tomcat 9.0.59
>  - link:https://issues.apache.org/jira/browse/TOMEE-3855[TOMEE-3855]
> Tomcat 9.0.60
>  - link:https://issues.apache.org/jira/browse/TOMEE-3856[TOMEE-3856]
> jackson 2.13.2
>  - link:https://issues.apache.org/jira/browse/TOMEE-3893[TOMEE-3893]
> jackson 2.13.2.2
>  - link:https://issues.apache.org/jira/browse/TOMEE-3886[TOMEE-3886]
> tomcat 9.0.62
> 
> == Bug
> 
> [.compact]
>  - link:https://issues.apache.org/jira/browse/TOMEE-3892[TOMEE-3892]
> TomEE Maven Plugin does not allow to override default "-ea" in
> RemoteServer
>  - link:https://issues.apache.org/jira/browse/TOMEE-3871[TOMEE-3871]
> TomEE Plume is missing BatchEE / JCS Cache
>  - link:https://issues.apache.org/jira/browse/TOMEE-3876[TOMEE-3876]
> BOM generation corrupted under windows (slash problems)
>  - link:https://issues.apache.org/jira/browse/TOMEE-3848[TOMEE-3848]
> Apache TomEE 8.0.6 onwards is packaged with quartz-2.2.4.jar
>  - link:https://issues.apache.org/jira/browse/TOMEE-3840[TOMEE-3840]
> TomEE WebProfile 8.0.9 does not start with security enabled
>  - link:https://issues.apache.org/jira/browse/TOMEE-3860[TOMEE-3860]
> Upgrade jackson-databind for CVE-2020-36518
> 
> == Improvement
> 
> [.compact]
>  - link:https://issues.apache.org/jira/browse/TOMEE-3851[TOMEE-3851]
> Replace Google Analytics with ASF Matomo
>  - link:https://issues.apache.org/jira/browse/TOMEE-3842[TOMEE-3842]
> GitHub Actions fails for PullRequest Builds due to BOM auto
> generation
>  - link:https://issues.apache.org/jira/browse/TOMEE-3859[TOMEE-3859]
> Update tomee.xml file so it refers to the right location
> 
> == Task
> 
> [.compact]
>  - link:https://issues.apache.org/jira/browse/TOMEE-3852[TOMEE-3852]
> Review the website in regard to external embedding of resources (JS,
> Fonts, CSS)
>  - link:https://issues.apache.org/jira/browse/TOMEE-3853[TOMEE-3853]
> Link ASF Privacy Policy from TomEE Website
> 
> == Documentation
> 
> [.compact]
>  - link:https://issues.apache.org/jira/browse/TOMEE-3894[TOMEE-3894]
> website generation broken under windows
>  - link:https://issues.apache.org/jira/browse/TOMEE-3854[TOMEE-3854]
> Provide a first draft of a link collection page targeting
> contributor/committer resources
>  - link:https://issues.apache.org/jira/browse/TOMEE-3888[TOMEE-3888]
> Cleanup documentation
>  - link:https://issues.apache.org/jira/browse/TOMEE-3846[TOMEE-3846]
> Inconsistence between tomee flavors comparison in website and actual
> jars
>  - link:https://issues.apache.org/jira/browse/TOMEE-3847[TOMEE-3847]
> Exception when building website from windows os
>  - link:https://issues.apache.org/jira/browse/TOMEE-3814[TOMEE-3814]
> Commented SSL Connector fix for tomee server.xml 
> 
> == Fixed Common Vulnerabilities and Exposures (CVEs)
> 
> [.compact]
>  - link:https://issues.apache.org/jira/browse/TOMEE-3893[TOMEE-3893]
> Upgrade to jackson 2.13.2.2
>  - link:https://issues.apache.org/jira/browse/TOMEE-3856[TOMEE-3856]
> Upgrade to jackson 2.13.2
>  - link:https://issues.apache.org/jira/browse/TOMEE-3860[TOMEE-3860]
> Upgrade jackson-databind for CVE-2020-36518
> 
> 
> Am Dienstag, dem 12.04.2022 um 11:14 +0200 schrieb Jean-Louis
> Monteiro:
> > Hi all,
> > 
> > We have a couple of important fixes and the CVE (Tomcat at least).
> > Is it ok to do a release?
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: Time for a TomEE 8.0.11 maintenance release?

[Zowalla, Richard]

+1

Question: We once talked about sharing knowledge about doing releases
[1], so I am wondering, if we should use 8.0.11 as a pilot test for
this approach?

For reference changes currently targeted for 8.0.11 (from Jira)
attached below.

Gruß 
Richard

[1] https://lists.apache.org/thread/dj0s8lldxlkqnfy43hwnclzwbgv40xht


== Dependency upgrade

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-3872[TOMEE-3872]
Hibernate Integration 5.6.7
 - link:https://issues.apache.org/jira/browse/TOMEE-3858[TOMEE-3858]
OpenJPA 3.2.2
 - link:https://issues.apache.org/jira/browse/TOMEE-3841[TOMEE-3841]
SLF4J 1.7.36
 - link:https://issues.apache.org/jira/browse/TOMEE-3845[TOMEE-3845]
Tomcat 9.0.59
 - link:https://issues.apache.org/jira/browse/TOMEE-3855[TOMEE-3855]
Tomcat 9.0.60
 - link:https://issues.apache.org/jira/browse/TOMEE-3856[TOMEE-3856]
jackson 2.13.2
 - link:https://issues.apache.org/jira/browse/TOMEE-3893[TOMEE-3893]
jackson 2.13.2.2
 - link:https://issues.apache.org/jira/browse/TOMEE-3886[TOMEE-3886]
tomcat 9.0.62

== Bug

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-3892[TOMEE-3892]
TomEE Maven Plugin does not allow to override default "-ea" in RemoteServer
 - link:https://issues.apache.org/jira/browse/TOMEE-3871[TOMEE-3871]
TomEE Plume is missing BatchEE / JCS Cache
 - link:https://issues.apache.org/jira/browse/TOMEE-3876[TOMEE-3876]
BOM generation corrupted under windows (slash problems)
 - link:https://issues.apache.org/jira/browse/TOMEE-3848[TOMEE-3848]
Apache TomEE 8.0.6 onwards is packaged with quartz-2.2.4.jar
 - link:https://issues.apache.org/jira/browse/TOMEE-3840[TOMEE-3840]
TomEE WebProfile 8.0.9 does not start with security enabled
 - link:https://issues.apache.org/jira/browse/TOMEE-3860[TOMEE-3860]
Upgrade jackson-databind for CVE-2020-36518

== Improvement

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-3851[TOMEE-3851]
Replace Google Analytics with ASF Matomo
 - link:https://issues.apache.org/jira/browse/TOMEE-3842[TOMEE-3842]
GitHub Actions fails for PullRequest Builds due to BOM auto generation
 - link:https://issues.apache.org/jira/browse/TOMEE-3859[TOMEE-3859]
Update tomee.xml file so it refers to the right location

== Task

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-3852[TOMEE-3852]
Review the website in regard to external embedding of resources (JS, Fonts, CSS)
 - link:https://issues.apache.org/jira/browse/TOMEE-3853[TOMEE-3853]
Link ASF Privacy Policy from TomEE Website

== Documentation

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-3894[TOMEE-3894]
website generation broken under windows
 - link:https://issues.apache.org/jira/browse/TOMEE-3854[TOMEE-3854]
Provide a first draft of a link collection page targeting contributor/committer 
resources
 - link:https://issues.apache.org/jira/browse/TOMEE-3888[TOMEE-3888]
Cleanup documentation
 - link:https://issues.apache.org/jira/browse/TOMEE-3846[TOMEE-3846]
Inconsistence between tomee flavors comparison in website and actual jars
 - link:https://issues.apache.org/jira/browse/TOMEE-3847[TOMEE-3847]
Exception when building website from windows os
 - link:https://issues.apache.org/jira/browse/TOMEE-3814[TOMEE-3814]
Commented SSL Connector fix for tomee server.xml 

== Fixed Common Vulnerabilities and Exposures (CVEs)

[.compact]
 - link:https://issues.apache.org/jira/browse/TOMEE-3893[TOMEE-3893]
Upgrade to jackson 2.13.2.2
 - link:https://issues.apache.org/jira/browse/TOMEE-3856[TOMEE-3856]
Upgrade to jackson 2.13.2
 - link:https://issues.apache.org/jira/browse/TOMEE-3860[TOMEE-3860]
Upgrade jackson-databind for CVE-2020-36518


Am Dienstag, dem 12.04.2022 um 11:14 +0200 schrieb Jean-Louis Monteiro:
> Hi all,
> 
> We have a couple of important fixes and the CVE (Tomcat at least).
> Is it ok to do a release?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com


smime.p7s
Description: S/MIME cryptographic signature

Re: TomEE MicroProfile and Jakarta

[Zowalla, Richard]

So we basically have to options (if I understand the discussion
correctly):

(A) Put some effort / resources into upgrade our MP impls to the latest
versions to fully support Jakarta namespace. From my understanding
maintaining these impls is a bit PITA as MP tends to break its API
every few months, right? It will take some time, effort and resources
to catch up.

(B) Use existing MP impls to make "fast" progress on the TomEE 9.x
side, which breaks the "we use apache impls"-credo but enables a faster
move forward. I see the danger here that we - due to lack of time /
resources - will not find the way back to our own Apache
implementations and will stick with smallrye for a long (?) time
perhaps.

People are eager to use EE9 / Jakarta namespace and TomEE isn't really
ready for it, yet. With the latest M7 version, users cannot start new
projects as testing possibilities are super limited.

Btw.: I am unsure, if we are still using Hibernate Validation in the
current TomEE 9-M8 Snapshot. But if we do, we already broke the
"everything from apache"-credo for the sake of getting the
certifaction. 

As I am too new to the whole context / strategy thing, I read this
discussion with great interest but do not have a strong opinion
regarding (A) or (B).

Gruß
Richard


Am Freitag, dem 01.04.2022 um 08:27 +0200 schrieb Romain Manni-Bucau:
> The risk for TomEE (IMHO indeed) is that, using smallrye, you break
> the
> core value "apache" or at least "owned by apache" and break the other
> core
> value "lightweight" since it comes with a tons of uneeded stuff and
> implementation is not even JAXRS friendly (it breaks literally jaxrs
> and
> cdi at multiple levels) so it can mean contributing to smallrye which
> means
> at the end asking mircoprofile to not be a spec but just an
> implementation
> and TomEE to stick to a dedicated MP distro (not in all others) to
> not kill
> itself - not saying it does not makes sense but it is what it means
> concretely.
> 
> 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. 31 mars 2022 à 21:36, David Blevins 
> a
> écrit :
> 
> > It would be great to see us have compliant MicroProfile
> > implementations
> > somewhere in Apache; Geronimo, TomEE, CXF.  It's still my personal
> > preference --  It makes very little sense to go through the effort
> > to
> > create a spec and tck to enable multiple implementations that can
> > compete/innovate and then wind up with just one implementation in
> > the
> > industry.
> > 
> > That said, from a TomEE perspective we're struggling to keep up
> > with all
> > specs, Jakarta EE and MicroProfile.  Part of that is we do try to
> > uniquely
> > implement specs, while everyone else just uses the exact same
> > implementation.  We're not really playing the same game.  We would
> > need
> > more resources than the competition to compete in the way we have
> > been
> > attempting.  However, because we're behind, we end up with fewer
> > resources
> > and larger gaps between implementations and over time our goals
> > becomes
> > harder, not easier.
> > 
> > I wonder if we should switch to the SmallRye implementations where
> > needed.  Not because we've given up hope of having Apache
> > implementations,
> > but because if we assume our desire to do the implementation work
> > here is a
> > constant and we know the time to get there will some number of
> > months and
> > that will likely be after complete our Jakarta EE spec work, which
> > is also
> > some number of months... we're basically talking sometime
> > 2023.  The
> > question then becomes, how do we want to spend our time till
> > then?  Do we
> > want to spend it in a compliant state or a non-compliant state?
> > 
> > If we spend the next year and change in a compliant state, using
> > the
> > SmallRye impls where needed until we've created compliant Apache
> > versions,
> > then we are competitive and will gain resources.  The date on which
> > we
> > would have resources to create those Apache implementations would
> > likely be
> > sooner.  If we spend the next year and change still not in a
> > compliant
> > state (as we've been since 2020), then we'l continue to take a
> > resource hit
> > and the date on which we would have resources to create those
> > Apache
> > implementations would likely be later.  There are also other risks
> > with
> > this approach.
> > 
> > So though it may seem backwards my gut says, unless we get a
> > dramatic
> > influx of resources from nowhere, we should use SmallRye where we
> > need
> > until we have the time to dedicate to the Apache implementations.
> > 
> > 
> > -David
> > 
> > 
> > > On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro <

Re: TOMEE-3846 flavors comparison page / TOMEE-3871 - TomEE Plume is missing BatchEE / JCS Cache

[Zowalla, Richard]

0/comparison.html
> > - https://tomee.apache.org/tomee-9.0/comparison.html
> > - https://tomee.apache.org/tomee-10.0/comparison.html (future)
> > 
> > We could potentially also list the Java version required.
> > 
> > The generic comparison.html page at 
> > https://tomee.apache.org/comparison.html could either stay as a
> > high-level view, or simply forward to the latest stable version
> > (which would be TomEE 8 at the moment).  We could also take a
> > different direction with the generic 
> > https://tomee.apache.org/comparison.html page and have it be kind
> > of a marketing page with fancy graphics to talk about each
> > distribution at a high level.  Sort of like the "TomEE Flavors"
> > section of our website main page (https://tomee.apache.org) but a
> > more complete page where there is kind of an image and description
> > of each distribution.  People can then use the more detailed
> > comparison pages for the full list of 40+ specifications we
> > support.
> > 
> > Thoughts?
> > 
> > 
> > -- 
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> > 
> > > On Mar 31, 2022, at 12:56 AM, Zowalla, Richard <
> > > richard.zowa...@hs-heilbronn.de> wrote:
> > > 
> > > I went ahead and merged the changes by Swell. @Swell: Thank you!!
> > > Cherry picked them to master (9.x) as well.
> > > 
> > > Now the distributions contain the libs specified on the website.
> > > 
> > > Gruß
> > > Richard
> > > 
> > > Am Montag, dem 28.03.2022 um 08:18 + schrieb Zowalla,
> > > Richard:
> > > > As we merged the comparision page, we should now tackle: 
> > > > https://github.com/apache/tomee/pull/828
> > > > 
> > > > There was a discussion regarding the original intentions of
> > > > plume.
> > > > If we agree, that "Those distributions are supposed to be the
> > > > same
> > > > minus the JPA and JSF providers.", then we should go a-head and
> > > > merge
> > > > it + port it to master.
> > > > 
> > > > Gruß
> > > > Richard
> > > > 
> > > > 
> > > > Am Freitag, dem 25.03.2022 um 11:29 +0100 schrieb Swell:
> > > > > Thanks for your kind feedback.
> > > > > 
> > > > > @Richard, I'll gladly change Tomee Plume pom to include
> > > > > BatchEE, PR
> > > > > :
> > > > > in
> > > > > progress with a blocker i can also resolve.
> > > > > 
> > > > > @David, about the flavors page, i think your suggestions are
> > > > > simpler
> > > > > and
> > > > > better, applied them on names consistency and added a table
> > > > > of
> > > > > implementations.
> > > > > 
> > > > > what need for this list of implementations ?
> > > > > * For my students => My usual scenario is that i need to
> > > > > remind
> > > > > them
> > > > > of
> > > > > what is provided by Tomee vs other servers. "they dont need
> > > > > HK2 nor
> > > > > Jersey
> > > > > if they have the Plus flavor."
> > > > > * For the general web site visitors => I wonder if people
> > > > > would
> > > > > prefer perf
> > > > > metrics and tck results, rather than comparing what is
> > > > > provided by
> > > > > Tomee vs
> > > > > others. provided a web capture just for fun :
> > > > > https://issues.apache.org/jira/secure/attachment/13041580/image-2022-03-25-11-18-14-708.png
> > > > > 
> > > > > i still believe the list of implementations is needed to know
> > > > > what
> > > > > Tomee
> > > > > provides, but David's suggestion is clearer.
> > > > > here is the current version of the web page in the PR :
> > > > > https://issues.apache.org/jira/secure/attachment/13041581/image-2022-03-25-11-19-03-406.png
> > > > > 
> > > > > On Fri, 25 Mar 2022 at 06:18, Zowalla, Richard <
> > > > > richard.zowa...@hs-heilbronn.de> wrote:
> > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > Thanks for your mail and your work in making the page mo

Re: TOMEE-3846 flavors comparison page

[Zowalla, Richard]

I went ahead and merged the changes by Swell. @Swell: Thank you!!
Cherry picked them to master (9.x) as well.

Now the distributions contain the libs specified on the website.

Gruß
Richard

Am Montag, dem 28.03.2022 um 08:18 + schrieb Zowalla, Richard:
> As we merged the comparision page, we should now tackle: 
> https://github.com/apache/tomee/pull/828
> 
> There was a discussion regarding the original intentions of plume.
> If we agree, that "Those distributions are supposed to be the same
> minus the JPA and JSF providers.", then we should go a-head and merge
> it + port it to master.
> 
> Gruß
> Richard
> 
> 
> Am Freitag, dem 25.03.2022 um 11:29 +0100 schrieb Swell:
> > Thanks for your kind feedback.
> > 
> > @Richard, I'll gladly change Tomee Plume pom to include BatchEE, PR
> > :
> > in
> > progress with a blocker i can also resolve.
> > 
> > @David, about the flavors page, i think your suggestions are
> > simpler
> > and
> > better, applied them on names consistency and added a table of
> > implementations.
> > 
> > what need for this list of implementations ?
> > * For my students => My usual scenario is that i need to remind
> > them
> > of
> > what is provided by Tomee vs other servers. "they dont need HK2 nor
> > Jersey
> > if they have the Plus flavor."
> > * For the general web site visitors => I wonder if people would
> > prefer perf
> > metrics and tck results, rather than comparing what is provided by
> > Tomee vs
> > others. provided a web capture just for fun :
> > https://issues.apache.org/jira/secure/attachment/13041580/image-2022-03-25-11-18-14-708.png
> > 
> > i still believe the list of implementations is needed to know what
> > Tomee
> > provides, but David's suggestion is clearer.
> > here is the current version of the web page in the PR :
> > https://issues.apache.org/jira/secure/attachment/13041581/image-2022-03-25-11-19-03-406.png
> > 
> > On Fri, 25 Mar 2022 at 06:18, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > > Hi all,
> > > 
> > > Thanks for your mail and your work in making the page more clear,
> > > Swell! Your work is very much appreciated.
> > > 
> > > 
> > > > Total side note to the wider dev list, we really need to get
> > > > JBatch
> > > > into Plume!  Those distributions are supposed to be the same
> > > > minus
> > > > the JPA and JSF providers.
> > > 
> > > I created TOMEE-3871 [1] for this one.
> > > 
> > > @Swell Let me know, if you like to provide a PR for master /
> > > tomee-
> > > 8.x
> > > branch to fix it. We can then assign you the Jira :)
> > > 
> > > It basically boils down to adding "batchee-jbatch" (runtime) to
> > > the
> > > "tomee-plume-webapp". The references in the "boms" are then
> > > automatically re-generated, if you conduct a quick build:
> > > 
> > > mvn -U -Pquick -DskipTests -Dsurefire.useFile=false
> > > -DdisableXmlReport=true -DuniqueVersion=false -ff -Dassemble
> > > -DfailIfNoTests=false clean install
> > > 
> > > If you are unsure how to proceed with it, feel free to ask. We
> > > are
> > > happy to help.
> > > 
> > > Gruß
> > > Richard
> > > 
> > > [1] https://issues.apache.org/jira/browse/TOMEE-3871
> > > 
> > > Am Donnerstag, dem 24.03.2022 um 11:48 -0700 schrieb David
> > > Blevins:
> > > > > On Mar 19, 2022, at 2:30 AM, Swell 
> > > > > wrote:
> > > > > 
> > > > > Regarding Tomee website : one web page mislead me to believe
> > > > > that
> > > > > Tomee Plus
> > > > > includes Tomee Plume, and it made it hard for me to
> > > > > understand
> > > > > why
> > > > > my
> > > > > webapp was not loading.
> > > > > 
> > > > > I believe it could mislead others and its why I wanted to
> > > > > suggest
> > > > > some
> > > > > changes on its content to better show the delta between
> > > > > flavors.
> > > > > 
> > > > > Currently the flavors page does not differentiate between
> > > > > Micro
> > > > > and
> > > > > Web
> > > > > profiles, nor does it tell Plume includes EclipseLink 

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Update regarding TOMEE-3879: We were missing --add-opens options in the
failover tests to run with Java 11+ - we added it to the bat / sh
scripts of openejb-standalone. However, bat / sh is not used in the
failover tests. 

I added the options in the tests, so TOMEE-3879 is fixed now.

Gruß
Richard

Am Dienstag, dem 29.03.2022 um 06:53 + schrieb Zowalla, Richard:
> Hi,
> 
> to follow up on TOMEE-3879 [1]: I add some more context to the Jira.
> The permissions do not matter as we are not invoking the scripts in
> bin/* in the failover itests (itests/failover). 
> 
> We are directly booting the servers via the java command (via
> Bootstrap
> from openejb-core) and a lot of properties to configure it, which
> fails
> (at least for me atm) with a ClassNotFoundException (see issue). Due
> to
> this exception, the servers never become ready and the tests will
> just
> timeout.
> 
> Don't have time to dig into it now but hope it helps anyone, who will
> work on it in the near future :)
> 
> Gruß
> Richard
> 
> [1] https://issues.apache.org/jira/browse/TOMEE-3879
> 
> Am Montag, dem 28.03.2022 um 08:16 + schrieb Zowalla, Richard:
> > Heyho,
> > 
> > the ZIP created for TOMEE-3879 looks good to me. It has +x set.
> > Perhaps
> > it looses the info during extraction in our code. 
> > 
> > Can you give a pointer, which tests are suspected to be impacted by
> > it?
> > 
> > Gruß
> > Richard
> > 
> > Am Samstag, dem 26.03.2022 um 10:40 +0100 schrieb Jean-Louis
> > Monteiro:
> > > Awesome, divide and conquer.
> > > 
> > > Trying to add a bit more...
> > > This one might be small for someone with some spare cycles.
> > > 
> > > https://issues.apache.org/jira/browse/TOMEE-3879
> > > 
> > > 
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > > 
> > > 
> > > On Sat, Mar 26, 2022 at 5:35 AM David Blevins <
> > > david.blev...@gmail.com>
> > > wrote:
> > > 
> > > > > On Mar 24, 2022, at 2:28 AM, Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com> wrote:
> > > > > We can now divide and conquer. An issue has been created
> > > > > https://issues.apache.org/jira/browse/TOMEE-3862
> > > > > We are going to add as many small tasks as possible so people
> > > > > can
> > > > > pick
> > > > and
> > > > > contribute in parallel.
> > > > 
> > > > Thanks for that JIRA.  I saw an easy one I could do and went a
> > > > head
> > > > and
> > > > knocked it out :)
> > > > 
> > > >  -
> > > > https://github.com/apache/tomee/commit/6e37ec02ca60fe955a3a909d761e09aa5a506978
> > > > 
> > > > That yanks 1 minute out of the build on my machine.
> > > > 
> > > > 
> > > > -David
> > > > 
> > > > 
> > > > > On Tue, Mar 22, 2022 at 1:59 PM Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com> wrote:
> > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I've been working for quite a long time on TomEE 9.x, and
> > > > > > it's
> > > > > > been more
> > > > > > challenging and painful than I was expecting. I thought it
> > > > > > would be
> > > > good to
> > > > > > give you some sort of status.
> > > > > > 
> > > > > > I created a PR for the work. As a reminder, since Java EE
> > > > > > moved
> > > > > > to
> > > > Eclipse
> > > > > > to become Jakarta EE, we had a switch from javax.*
> > > > > > namespace
> > > > > > to
> > > > jakarta.*
> > > > > > namespace. This is an impacting change, since all
> > > > > > applications
> > > > > > and
> > > > > > applications servers are built on top of it.
> > > > > > 
> > > > > > In TomEE, we decided to do that change in TomEE. We had
> > > > > > previously a
> > > > > > bytecode change approach like an application could do. It
> > > > > > worked and we
> > > > > > were able to get certified. But it had a lot of
> > > > > > limitations,
> > >

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Hi,

to follow up on TOMEE-3879 [1]: I add some more context to the Jira.
The permissions do not matter as we are not invoking the scripts in
bin/* in the failover itests (itests/failover). 

We are directly booting the servers via the java command (via Bootstrap
from openejb-core) and a lot of properties to configure it, which fails
(at least for me atm) with a ClassNotFoundException (see issue). Due to
this exception, the servers never become ready and the tests will just
timeout.

Don't have time to dig into it now but hope it helps anyone, who will
work on it in the near future :)

Gruß
Richard

[1] https://issues.apache.org/jira/browse/TOMEE-3879

Am Montag, dem 28.03.2022 um 08:16 + schrieb Zowalla, Richard:
> Heyho,
> 
> the ZIP created for TOMEE-3879 looks good to me. It has +x set.
> Perhaps
> it looses the info during extraction in our code. 
> 
> Can you give a pointer, which tests are suspected to be impacted by
> it?
> 
> Gruß
> Richard
> 
> Am Samstag, dem 26.03.2022 um 10:40 +0100 schrieb Jean-Louis
> Monteiro:
> > Awesome, divide and conquer.
> > 
> > Trying to add a bit more...
> > This one might be small for someone with some spare cycles.
> > 
> > https://issues.apache.org/jira/browse/TOMEE-3879
> > 
> > 
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> > 
> > 
> > On Sat, Mar 26, 2022 at 5:35 AM David Blevins <
> > david.blev...@gmail.com>
> > wrote:
> > 
> > > > On Mar 24, 2022, at 2:28 AM, Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com> wrote:
> > > > We can now divide and conquer. An issue has been created
> > > > https://issues.apache.org/jira/browse/TOMEE-3862
> > > > We are going to add as many small tasks as possible so people
> > > > can
> > > > pick
> > > and
> > > > contribute in parallel.
> > > 
> > > Thanks for that JIRA.  I saw an easy one I could do and went a
> > > head
> > > and
> > > knocked it out :)
> > > 
> > >  -
> > > https://github.com/apache/tomee/commit/6e37ec02ca60fe955a3a909d761e09aa5a506978
> > > 
> > > That yanks 1 minute out of the build on my machine.
> > > 
> > > 
> > > -David
> > > 
> > > 
> > > > On Tue, Mar 22, 2022 at 1:59 PM Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com> wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > I've been working for quite a long time on TomEE 9.x, and
> > > > > it's
> > > > > been more
> > > > > challenging and painful than I was expecting. I thought it
> > > > > would be
> > > good to
> > > > > give you some sort of status.
> > > > > 
> > > > > I created a PR for the work. As a reminder, since Java EE
> > > > > moved
> > > > > to
> > > Eclipse
> > > > > to become Jakarta EE, we had a switch from javax.* namespace
> > > > > to
> > > jakarta.*
> > > > > namespace. This is an impacting change, since all
> > > > > applications
> > > > > and
> > > > > applications servers are built on top of it.
> > > > > 
> > > > > In TomEE, we decided to do that change in TomEE. We had
> > > > > previously a
> > > > > bytecode change approach like an application could do. It
> > > > > worked and we
> > > > > were able to get certified. But it had a lot of limitations,
> > > > > so
> > > > > we had
> > > to
> > > > > do the migration in the code and fix all compatibility
> > > > > issues.
> > > > > 
> > > > > Here is the PR https://github.com/apache/tomee/pull/814
> > > > > It has 90+ commits and nearly 5000 files touched (added,
> > > > > removed,
> > > > > updated). I understand it's a lot and it makes it almost
> > > > > impossible to
> > > > > review. But I did not see much approaches in this scenario to
> > > > > create
> > > > > smaller PRs.
> > > > > 
> > > > > I created a Jenkins build though available at
> > > > > https://ci-builds.apache.org/job/Tomee/job/master-build-quick-9.x/
> > > > > 
> > > > > It makes it possible to track the progress. There have been
> 

Re: TOMEE-3846 flavors comparison page

[Zowalla, Richard]

As we merged the comparision page, we should now tackle: 
https://github.com/apache/tomee/pull/828

There was a discussion regarding the original intentions of plume.
If we agree, that "Those distributions are supposed to be the same
minus the JPA and JSF providers.", then we should go a-head and merge
it + port it to master.

Gruß
Richard


Am Freitag, dem 25.03.2022 um 11:29 +0100 schrieb Swell:
> Thanks for your kind feedback.
> 
> @Richard, I'll gladly change Tomee Plume pom to include BatchEE, PR :
> in
> progress with a blocker i can also resolve.
> 
> @David, about the flavors page, i think your suggestions are simpler
> and
> better, applied them on names consistency and added a table of
> implementations.
> 
> what need for this list of implementations ?
> * For my students => My usual scenario is that i need to remind them
> of
> what is provided by Tomee vs other servers. "they dont need HK2 nor
> Jersey
> if they have the Plus flavor."
> * For the general web site visitors => I wonder if people would
> prefer perf
> metrics and tck results, rather than comparing what is provided by
> Tomee vs
> others. provided a web capture just for fun :
> https://issues.apache.org/jira/secure/attachment/13041580/image-2022-03-25-11-18-14-708.png
> 
> i still believe the list of implementations is needed to know what
> Tomee
> provides, but David's suggestion is clearer.
> here is the current version of the web page in the PR :
> https://issues.apache.org/jira/secure/attachment/13041581/image-2022-03-25-11-19-03-406.png
> 
> On Fri, 25 Mar 2022 at 06:18, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Hi all,
> > 
> > Thanks for your mail and your work in making the page more clear,
> > Swell! Your work is very much appreciated.
> > 
> > 
> > > Total side note to the wider dev list, we really need to get
> > > JBatch
> > > into Plume!  Those distributions are supposed to be the same
> > > minus
> > > the JPA and JSF providers.
> > 
> > I created TOMEE-3871 [1] for this one.
> > 
> > @Swell Let me know, if you like to provide a PR for master / tomee-
> > 8.x
> > branch to fix it. We can then assign you the Jira :)
> > 
> > It basically boils down to adding "batchee-jbatch" (runtime) to the
> > "tomee-plume-webapp". The references in the "boms" are then
> > automatically re-generated, if you conduct a quick build:
> > 
> > mvn -U -Pquick -DskipTests -Dsurefire.useFile=false
> > -DdisableXmlReport=true -DuniqueVersion=false -ff -Dassemble
> > -DfailIfNoTests=false clean install
> > 
> > If you are unsure how to proceed with it, feel free to ask. We are
> > happy to help.
> > 
> > Gruß
> > Richard
> > 
> > [1] https://issues.apache.org/jira/browse/TOMEE-3871
> > 
> > Am Donnerstag, dem 24.03.2022 um 11:48 -0700 schrieb David Blevins:
> > > > On Mar 19, 2022, at 2:30 AM, Swell 
> > > > wrote:
> > > > 
> > > > Regarding Tomee website : one web page mislead me to believe
> > > > that
> > > > Tomee Plus
> > > > includes Tomee Plume, and it made it hard for me to understand
> > > > why
> > > > my
> > > > webapp was not loading.
> > > > 
> > > > I believe it could mislead others and its why I wanted to
> > > > suggest
> > > > some
> > > > changes on its content to better show the delta between
> > > > flavors.
> > > > 
> > > > Currently the flavors page does not differentiate between Micro
> > > > and
> > > > Web
> > > > profiles, nor does it tell Plume includes EclipseLink when Plus
> > > > does not.
> > > > 
> > > > I took time to write a page I believe could be usefull to Tomee
> > > > users, a
> > > > screenshot is linked below, the visitors could benefit from my
> > > > additional
> > > > table for synthesis of deltas.
> > > > 
> > > > 
> > https://issues.apache.org/jira/secure/attachment/13041318/image-2022-03-18-20-36-25-938.png
> > > Hi Swell,
> > > 
> > > Thank you so much for taking the time to put so much thought into
> > > this work.  We are truly lucky :)
> > > 
> > > I love that you included the MicroProfile detail, that was
> > > definitely
> > > missing and badly needed.  As the table is quite large already,
> > > that
> > > terse summary at the top is 

Re: TomEE 9.x - from javax to jakarta namespace

[Zowalla, Richard]

Heyho,

the ZIP created for TOMEE-3879 looks good to me. It has +x set. Perhaps
it looses the info during extraction in our code. 

Can you give a pointer, which tests are suspected to be impacted by it?

Gruß
Richard

Am Samstag, dem 26.03.2022 um 10:40 +0100 schrieb Jean-Louis Monteiro:
> Awesome, divide and conquer.
> 
> Trying to add a bit more...
> This one might be small for someone with some spare cycles.
> 
> https://issues.apache.org/jira/browse/TOMEE-3879
> 
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Sat, Mar 26, 2022 at 5:35 AM David Blevins <
> david.blev...@gmail.com>
> wrote:
> 
> > > On Mar 24, 2022, at 2:28 AM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> > > We can now divide and conquer. An issue has been created
> > > https://issues.apache.org/jira/browse/TOMEE-3862
> > > We are going to add as many small tasks as possible so people can
> > > pick
> > and
> > > contribute in parallel.
> > 
> > Thanks for that JIRA.  I saw an easy one I could do and went a head
> > and
> > knocked it out :)
> > 
> >  -
> > https://github.com/apache/tomee/commit/6e37ec02ca60fe955a3a909d761e09aa5a506978
> > 
> > That yanks 1 minute out of the build on my machine.
> > 
> > 
> > -David
> > 
> > 
> > > On Tue, Mar 22, 2022 at 1:59 PM Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > I've been working for quite a long time on TomEE 9.x, and it's
> > > > been more
> > > > challenging and painful than I was expecting. I thought it
> > > > would be
> > good to
> > > > give you some sort of status.
> > > > 
> > > > I created a PR for the work. As a reminder, since Java EE moved
> > > > to
> > Eclipse
> > > > to become Jakarta EE, we had a switch from javax.* namespace to
> > jakarta.*
> > > > namespace. This is an impacting change, since all applications
> > > > and
> > > > applications servers are built on top of it.
> > > > 
> > > > In TomEE, we decided to do that change in TomEE. We had
> > > > previously a
> > > > bytecode change approach like an application could do. It
> > > > worked and we
> > > > were able to get certified. But it had a lot of limitations, so
> > > > we had
> > to
> > > > do the migration in the code and fix all compatibility issues.
> > > > 
> > > > Here is the PR https://github.com/apache/tomee/pull/814
> > > > It has 90+ commits and nearly 5000 files touched (added,
> > > > removed,
> > > > updated). I understand it's a lot and it makes it almost
> > > > impossible to
> > > > review. But I did not see much approaches in this scenario to
> > > > create
> > > > smaller PRs.
> > > > 
> > > > I created a Jenkins build though available at
> > > > https://ci-builds.apache.org/job/Tomee/job/master-build-quick-9.x/
> > > > 
> > > > It makes it possible to track the progress. There have been
> > > > steps
> > forward
> > > > and steps backward.
> > > > 
> > > > All the code does not sit under TomEE, we use a bunch of third
> > > > party
> > > > projects and libraries. I have been able to contribute, publish
> > > > jakarta
> > > > compatible versions and get releases for some of them (Jakarta
> > > > EE APIs
> > Uber
> > > > jar, Geronimo Connectors and Transaction Manager, Geronimo
> > > > Config,
> > Health,
> > > > Metrics, OpenTracing, OpenAPI. OpenJPA, BVal, and OpenWebBeans
> > > > will be
> > > > released soon.
> > > > 
> > > > The big parts is CXF, and ActiveMQ. I had to get them done in
> > > > TomEE and
> > > > update all group/artifact ids. It's under deps, alongside with
> > > > SXC,
> > DBCP,
> > > > and others.
> > > > 
> > > > In terms of removal, I tried to remove old stuff like SAAJ Axis
> > > > 1
> > > > integration, JAX RPC, Management J2EE and a couple of other old
> > > > things.
> > > > 
> > > > A lot of other libraries got updated to their latest version
> > > > when
> > > > available in the new jakarta namespace.
> > > > 
> > > > I'm starting to get all the build stable and many modules are
> > > > passing
> > now,
> > > > including all CXF webservices, OpenEJB Core, and others. I can
> > > > get a
> > build
> > > > and run TomEE.
> > > > 
> > > > Goal is to get a green build asap so we can start working on
> > > > TCK.
> > > > The "quick" build is now green. Working on the full build.
> > > > 
> > > > I'll soon be creating a branch for TomEE 8.x maintenance and
> > > > merge the
> > PR.
> > > > I'm hoping we can then have small PRs or at least more people
> > > > working in
> > > > parallel.
> > > > 
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: TOMEE-3846 flavors comparison page

[Zowalla, Richard]

Hi all,

Thanks for your mail and your work in making the page more clear,
Swell! Your work is very much appreciated.


> Total side note to the wider dev list, we really need to get JBatch
> into Plume!  Those distributions are supposed to be the same minus
> the JPA and JSF providers.

I created TOMEE-3871 [1] for this one.

@Swell Let me know, if you like to provide a PR for master / tomee-8.x
branch to fix it. We can then assign you the Jira :)

It basically boils down to adding "batchee-jbatch" (runtime) to the
"tomee-plume-webapp". The references in the "boms" are then
automatically re-generated, if you conduct a quick build: 

mvn -U -Pquick -DskipTests -Dsurefire.useFile=false
-DdisableXmlReport=true -DuniqueVersion=false -ff -Dassemble
-DfailIfNoTests=false clean install

If you are unsure how to proceed with it, feel free to ask. We are
happy to help.

Gruß
Richard

[1] https://issues.apache.org/jira/browse/TOMEE-3871

Am Donnerstag, dem 24.03.2022 um 11:48 -0700 schrieb David Blevins:
> > On Mar 19, 2022, at 2:30 AM, Swell 
> > wrote:
> > 
> > Regarding Tomee website : one web page mislead me to believe that
> > Tomee Plus
> > includes Tomee Plume, and it made it hard for me to understand why
> > my
> > webapp was not loading.
> > 
> > I believe it could mislead others and its why I wanted to suggest
> > some
> > changes on its content to better show the delta between flavors.
> > 
> > Currently the flavors page does not differentiate between Micro and
> > Web
> > profiles, nor does it tell Plume includes EclipseLink when Plus
> > does not.
> > 
> > I took time to write a page I believe could be usefull to Tomee
> > users, a
> > screenshot is linked below, the visitors could benefit from my
> > additional
> > table for synthesis of deltas.
> > 
> > https://issues.apache.org/jira/secure/attachment/13041318/image-2022-03-18-20-36-25-938.png
> 
> Hi Swell,
> 
> Thank you so much for taking the time to put so much thought into
> this work.  We are truly lucky :)
> 
> I love that you included the MicroProfile detail, that was definitely
> missing and badly needed.  As the table is quite large already, that
> terse summary at the top is a very nice improvement and likely to
> help people see the big picture significantly faster.
> 
> In the first table, I like the way you used "Jakarta JSF
> Implementation" and list the implementations by name.  For
> consistency, can we use that same approach for the line
> above?  Instead of it saying "EclipseLink" and having a checkmark,
> could we also have it say "Jakarta Persistence (JPA) Implementation"
> and then put "OpenJPA, OpenJPA, EcliseLink, OpenJPA" in there?  We
> can do that in both the top and bottom tables.
> 
> On listing OpenEJB in the bottom table.  I think it's fine  I'm not
> the best judge of what people think is useful information as I've
> been working on the project too long and everything is "obvious."  Do
> you find it helpful to see OpenEJB listed even though it's the same
> for all distributions.  Do you think we possibly need a table
> entirely dedicated to implementations? (OpenWebBeans, Geronimo
> Transaction Manager, BVal, etc)
> 
> Some minor trademark corrections:
> 
>  - "GlassFish Mojarra" is "Eclipse Mojarra"
>  - "Jakarta JSF" is "Jakarta Faces", but "Jakarta Faces (JSF)" is
> completely fine and encouraged so people are aware of its new and
> former name.
>  - "Jakarta EJB" is "Jakarta Enterprise Beans", but "Jakarta
> Enterprise Beans (EJB)" is completely fine and encouraged so people
> are aware of its new and former name.
>  - "Jakarta JPA" is "Jakarta Persistence", but "Jakarta Persistence
> (JPA)" is completely fine and encouraged so people are aware of its
> new and former name.
>  - OpenJPA, OpenEJB and MyFaces are all Apache trademarks, so if
> we're going to say "Apache MyFaces" on the page, we need to also use
> "Apache OpenJPA" and "Apache OpenEJB"
> 
> 
> Total side note to the wider dev list, we really need to get JBatch
> into Plume!  Those distributions are supposed to be the same minus
> the JPA and JSF providers.
> 
> 
> Thank you so much, again, for all work on this and being patient
> getting bounced around between different repos and ultimately onto
> the list.  We'd be happy to see you post as often as you like :)
> 
> 
> -David
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Helping with Releases (Re: TomEE KEYS update)

[Zowalla, Richard]

I like the idea of pairing people to act as release managers. That is a
great way to transfer knowledge and open the circle of people "who
know". 

By doing so, it might be even possible to have some sort of (mostly) up
2 date release documentation, which could then be integrated in the
release tools. A checklist as a starter (or a script in the next
iteration) is also a good thing + the 4 eye principle. 

If we have some sort of "structured" documentation / approach, we could
try to automate parts of it leveraging CI tools available at ASF (which
might have some restriction due to INFRA restrictions).

> A significant blocker, however, is that a large number of the steps
> can't be done unless you're an Apache committer.  Not because of
> policy, just because they require access to systems only committers
> can reach.  You won't be able to run a lot of the commands.

In addition, it seems that even a "normal" committer cannot act as
release manager unless a special request is sent to INFRA [2] and the
particular access rights are granted. I don't know, if this was already
requested for TomEE ;)

To add some additional things, which we tend to make different from
times to times:

- Creation of Release Notes: We sometimes use the JIRA feature to show
our changes or use the release-tools to create the .adoc file, which is
then put on the website, too. In the past, we didn't create proper
relese notes for our website and peope had to dig into Jira to find
them. I like our current approach (since 9-M7) by adding dedicated
release notes to the website much more. They are even referenced on
Stackoverflow now *lol*.

Gruß
Richard

[1] https://infra.apache.org/release-publishing.html#releasemanager


Am Donnerstag, dem 17.03.2022 um 17:50 -0700 schrieb David Blevins:
> Digging up this old thread as any offer to help really deserves a
> response.  I had travelled to help dear old mom these two weeks and
> didn't get back to you after I had a bit more bandwidth.
> 
> > On Sep 18, 2021, at 9:31 AM, Jenkins, Rodney J (Rod) <
> > jenki...@nationwide.com> wrote:
> > 
> > David,
> > 
> > Thank you for the insights and explanation!
> > 
> > I completely understand the technical debt and the challenge of
> > making this better during a release.  I would like to jump in and
> > see where I can help.  My problem is I am not a java
> > developer.  What I am good it is automating tasks, if I can be
> > taught to execute them.
> > 
> > The big ask is:  Would anyone want to take the time with me to
> > educate me on what has to happen for a release (not during a
> > release)?  I am thinking that we could set up a dummy repo that has
> > some simple small java code in it to be a dummy TomEE release
> > candidate.  Create some dummy destinations that mimic where the
> > artifacts must be placed.  Once I understand the process, I can see
> > about making it repeatable.
> > 
> > Personally, I would like to see it done in a way that someone with
> > lesser skills (like, but not necessarily,  me) does releases.  The
> > way I see it now is the heavy hitters do the releases.  I think
> > their time would be better spent on the technical debt, bugs,
> > etc.  Maybe we could find a small few that would be wiling the be
> > release specialists.  I know some where I work that MAY be
> > interested.  If someone would teach me, I would teach them.
> 
> You have the right spirit.  In the early days of Geronimo I did the
> majority of releases and while I did a good job, wasn't the job I
> wanted to be doing and could see how me doing all the releases
> created a knowledge vacuum that actually hurts the community.
> 
> What I did was suggest we start a system where each release had a
> pilot and a copilot.  The pilot would be an experienced person who
> know what they were doing, the copilot would be someone
> learning.  Next release the copilot would become the pilot and do the
> release and a new person would become the copilot.  Each release the
> documentation got a bit better, the technical debt paid down a
> bit.  Things improved, releases got more frequent and quality went
> up.
> 
> A significant blocker, however, is that a large number of the steps
> can't be done unless you're an Apache committer.  Not because of
> policy, just because they require access to systems only committers
> can reach.  You won't be able to run a lot of the commands.
> 
> That's not a show stopper, it just means it our creativity in how to
> leverage you will be heavily challenged.  I'm up for it if you are.
> 
> I have been trying to revitalize our release tools in java for
> automating as many release tasks as possible.  I do think that's the
> right way to go as the majority of people who do releases are java
> developers.  In the past I've written elaborate scripts in bash and
> inevitably they decay as I'd be the only one who understood
> them.  That doesn't necessarily mean there's no role for scripting.
> 
> One of the hardest parts of doing releases