Re: [PR] [TOMEE-4402] Remove JCache (JSR 107) API and its implementation (tomee)
JCache in itself is isolated, yes. But many implementations (RI, Geronimo simple, JCS) also bring CDI integration code so you can actually use JCache annotations without interacting directly with the CacheManager. As far as I'm aware there is no implementation that provides this CDI integration for modern (= jakarta) versions of CDI, not even something that is shaded. This and the fact that the spec has been abandoned for more or less +5 years lead me to the conclusion that at least JCache + CDI is dead right now. We could keep a plain JCache impl in TomEE, but IMO this is out of scope. TomEE wants to be a Jakarta EE (+ microprofile) implementation, JCache is neither of those right now. My opinion isn't too strong on this matter, but these are the reasons why I removed this for now. If we find we want to keep it we can always revert. Am 16. September 2024 23:17:19 MESZ schrieb Mark Struberg : > There are quite a few specs in the javax namespace still. If they are > isolated it's imo fine to include them. It's just another 'optional' library. > And a very useful indeed! >It's imo a matter of time when it will finally get moved over to jakarta. >LieGrue,strub > >On Monday, 16 September 2024 at 14:15:36 CEST, jungm (via GitHub) > wrote: > > >jungm opened a new pull request, #1497: >URL: https://github.com/apache/tomee/pull/1497 > > See https://issues.apache.org/jira/browse/TOMEE-4402 > JCache was afaik never part of the Jakarta EE specification and JCS is still >using the javax.* namespace for CDI > > So this has been broken since the first TomEE 9 releases but nobody >complained > >
Re: SXC Rework
+1 for all your proposed steps Am 13. September 2024 09:15:04 MESZ schrieb Richard Zowalla : >Hi all, > >to move forward targeting an M3 to get feedback, I would propose, that we do >the following: > >(1) We include https://github.com/apache/tomee/pull/1469 with the re-generated >accessors from the Jakarta-moved SXC (source: https://github.com/rzo1/sxc) >version. Given that metatype.org is gone (not registered anymore), we cannot >use that domain for publishing to Maven Central. > >(2) Include the completed and passing concurrency impl with enabled SXC and >updated accessors needed for it in https://github.com/apache/tomee/pull/1458 > >(3) If everything works out well, we could (imho) experiment with generating >the accessors during the build, but not a requirement imho. > >(4) If we have (1) and (2), we should do a M3 to get feedback on the SXC >changes as well as on the concurrency side of things. Since CXF 4.1.0 is still >not released, we need to do the fork-release appraoch for M3 again. > >WDYT? > >Gruß >Richard > >On 2024/09/09 11:49:59 Markus Jung wrote: >> The JAXB RI seems to have removed the code that generates and loads accessor >> bytecode as the Injector [1] looks like it is unused. So initializing JAXB >> has probably gotten a lot faster compared to when SXC was introduced in >> tomee. >> >> However, JAXB Context initialization still takes significantly longer than >> just invoking SXC code. As Richard said, I did a very basic benchmark >> deserializing a-faces-config-22.xml from FacesConfig22Test just to get a >> feeling of how big the gap is: >> >> sxc1: 30ms >> sxc2: 2ms >> jaxb1: 278ms >> jaxb2: 4ms >> >> Once the JAXB Context is initialized and “warmed up” the gap is really >> insignificant. But what we do care about is initial startup performance. >> JAXB needs to do a ton of reflection to build an internal meta model while >> SXC moves a lot of this work to build time by generating source code. Note >> that I only compared the pure time it takes to unmarshal a String in memory, >> total time with JVM startup etc is probably a bit slower as there are right >> now 271 more classes to load that SXC generated. But likely still a lot >> faster than just using JAXB RI. >> >> >> [1] >> https://github.com/eclipse-ee4j/jaxb-ri/blob/4.0.5-RI/jaxb-ri/runtime/impl/src/main/java/org/glassfish/jaxb/runtime/v2/runtime/reflect/opt/Injector.java >> >> > On 9. Sep 2024, at 10:21, Richard Zowalla wrote: >> > >> > I think, that Markus did some tests. Maybe he can share? :) >> > >> >> Am 09.09.2024 um 09:48 schrieb Jean-Louis Monteiro >> >> : >> >> >> >> Is the performance reason still accurate nowadays? >> >> Someone tested with recent JVMs? >> >> -- >> >> Jean-Louis Monteiro >> >> http://twitter.com/jlouismonteiro >> >> http://www.tomitribe.com >> >> >> >> >> >> On Mon, Sep 9, 2024 at 9:30 AM Richard Zowalla wrote: >> >> >> >>> Any other thoughts? >> >>> >> >>>> Am 05.09.2024 um 11:08 schrieb Richard Zowalla : >> >>>> >> >>>> Yes. It is done for startup performance reasons only. At runtime, there >> >>> is not a big difference. >> >>>> Regarding your points. >> >>>> >> >>>> (1) I think, that metatype.org <http://metatype.org/> has expired / is >> >>> parked at a domain service, so it might not be possible to release SXC >> >>> under that umbrella (again). We cannot put that under the ASF umbrella >> >>> because of licensing constraints. >> >>>> (2) The build looks good (as far as I can remember) and if we have >> >>> regressions in that area, we will find out with our early adopters in an >> >>> M3 >> >>> milestone. >> >>>> (3) I am fine with that but would see that in a next stage ;-) >> >>>> >> >>>> Thanks for the work, Markus. It is really appreciated! >> >>>> >> >>>> Gruß >> >>>> Richard >> >>>> >> >>>>> Am 03.09.2024 um 16:16 schrieb Markus Jung : >> >>>>> >> >>>>> AFAIK sticking to SXC is a decision purely made for startup performance >> >>> reasons, see David's reply in >> >>> https://lists.apache.org/thread/09powc11z4rnzvyzmt4xy5bcbrqwk
Re: SXC Rework
The JAXB RI seems to have removed the code that generates and loads accessor bytecode as the Injector [1] looks like it is unused. So initializing JAXB has probably gotten a lot faster compared to when SXC was introduced in tomee. However, JAXB Context initialization still takes significantly longer than just invoking SXC code. As Richard said, I did a very basic benchmark deserializing a-faces-config-22.xml from FacesConfig22Test just to get a feeling of how big the gap is: sxc1: 30ms sxc2: 2ms jaxb1: 278ms jaxb2: 4ms Once the JAXB Context is initialized and “warmed up” the gap is really insignificant. But what we do care about is initial startup performance. JAXB needs to do a ton of reflection to build an internal meta model while SXC moves a lot of this work to build time by generating source code. Note that I only compared the pure time it takes to unmarshal a String in memory, total time with JVM startup etc is probably a bit slower as there are right now 271 more classes to load that SXC generated. But likely still a lot faster than just using JAXB RI. [1] https://github.com/eclipse-ee4j/jaxb-ri/blob/4.0.5-RI/jaxb-ri/runtime/impl/src/main/java/org/glassfish/jaxb/runtime/v2/runtime/reflect/opt/Injector.java > On 9. Sep 2024, at 10:21, Richard Zowalla wrote: > > I think, that Markus did some tests. Maybe he can share? :) > >> Am 09.09.2024 um 09:48 schrieb Jean-Louis Monteiro >> : >> >> Is the performance reason still accurate nowadays? >> Someone tested with recent JVMs? >> -- >> Jean-Louis Monteiro >> http://twitter.com/jlouismonteiro >> http://www.tomitribe.com >> >> >> On Mon, Sep 9, 2024 at 9:30 AM Richard Zowalla wrote: >> >>> Any other thoughts? >>> >>>> Am 05.09.2024 um 11:08 schrieb Richard Zowalla : >>>> >>>> Yes. It is done for startup performance reasons only. At runtime, there >>> is not a big difference. >>>> Regarding your points. >>>> >>>> (1) I think, that metatype.org <http://metatype.org/> has expired / is >>> parked at a domain service, so it might not be possible to release SXC >>> under that umbrella (again). We cannot put that under the ASF umbrella >>> because of licensing constraints. >>>> (2) The build looks good (as far as I can remember) and if we have >>> regressions in that area, we will find out with our early adopters in an M3 >>> milestone. >>>> (3) I am fine with that but would see that in a next stage ;-) >>>> >>>> Thanks for the work, Markus. It is really appreciated! >>>> >>>> Gruß >>>> Richard >>>> >>>>> Am 03.09.2024 um 16:16 schrieb Markus Jung : >>>>> >>>>> AFAIK sticking to SXC is a decision purely made for startup performance >>> reasons, see David's reply in >>> https://lists.apache.org/thread/09powc11z4rnzvyzmt4xy5bcbrqwkfkh >>>>> >>>>> On 03.09.24 13:43, Thomas Andraschko wrote: >>>>>> i thought it in the past that i would be better to get rid of SXC >>>>>> completely but maybe thats a to big task: >>>>>> https://lists.apache.org/thread/0p4m1rw8vmv17l29s1lgclsd9bfrr7s4 >>>>>> >>>>>> Am Di., 3. Sept. 2024 um 13:15 Uhr schrieb Markus Jung < >>> ju...@apache.org>: >>>>>> >>>>>>> Hey all, >>>>>>> >>>>>>> >>>>>>> I had to modify the JAXB models in openejb-jee for the concurrency 3.0 >>>>>>> implementation [1] but noticed the changes were not taken into affect. >>>>>>> This is where I found out what openejb-jee-accessors was for. >>>>>>> >>>>>>> Long story short, I was not able to get the old SXC maven plugin >>> running >>>>>>> and Richard and I decided to fork SXC and update it to Jakarta XML >>>>>>> Binding 4.0. The fork can be found here [2] and Richard has done a >>>>>>> release on maven central under the groupId >>>>>>> io.github.rzo1.org.metatype.sxc. I integrated this new SXC release in >>> a >>>>>>> PR [3] and would highly appreciate if we can get some eyes from long >>>>>>> time contributors on this. >>>>>>> >>>>>>> I think there are 3 topics that require attention: >>>>>>> 1. Do we want to switch to Richards fork? Maybe we could merge with >>> the >>>>>>> origin
Re: SXC Rework
AFAIK sticking to SXC is a decision purely made for startup performance reasons, see David's reply in https://lists.apache.org/thread/09powc11z4rnzvyzmt4xy5bcbrqwkfkh On 03.09.24 13:43, Thomas Andraschko wrote: i thought it in the past that i would be better to get rid of SXC completely but maybe thats a to big task: https://lists.apache.org/thread/0p4m1rw8vmv17l29s1lgclsd9bfrr7s4 Am Di., 3. Sept. 2024 um 13:15 Uhr schrieb Markus Jung : Hey all, I had to modify the JAXB models in openejb-jee for the concurrency 3.0 implementation [1] but noticed the changes were not taken into affect. This is where I found out what openejb-jee-accessors was for. Long story short, I was not able to get the old SXC maven plugin running and Richard and I decided to fork SXC and update it to Jakarta XML Binding 4.0. The fork can be found here [2] and Richard has done a release on maven central under the groupId io.github.rzo1.org.metatype.sxc. I integrated this new SXC release in a PR [3] and would highly appreciate if we can get some eyes from long time contributors on this. I think there are 3 topics that require attention: 1. Do we want to switch to Richards fork? Maybe we could merge with the original code from David and release that again, though it seems the metatype.org domain is expired and owned by a parking service. We likely can't fork it in tomee as the code is not fully under the Apache 2.0 License. 2. Some tests were failing after I fully regenerated the SXC accessor classes because the generated code has been modified in some places to allow unknown XML nodes. I recreated this behavior by adding @XmlAnyAttribute annotated fields where needed. We should be double checking that I did not miss anything. 3. (optional) The accessors are 100% matching the JAXB model now. IMO we should highly consider to delete these from the repository and treat them as generated sources. This would remove tens of thousands of lines of code and force future developers to make adjustments in the JAXB Model instead of hiding them in generated code. WDYT? Any feedback would be highly appreciated as this is a pretty significant change. The diff for the PR that regenerates all accessors [3] is 30k+ lines long. Thanks Markus [1] https://github.com/apache/tomee/pull/1458 [2] https://github.com/rzo1/sxc [3] https://github.com/apache/tomee/pull/1469
SXC Rework
Hey all, I had to modify the JAXB models in openejb-jee for the concurrency 3.0 implementation [1] but noticed the changes were not taken into affect. This is where I found out what openejb-jee-accessors was for. Long story short, I was not able to get the old SXC maven plugin running and Richard and I decided to fork SXC and update it to Jakarta XML Binding 4.0. The fork can be found here [2] and Richard has done a release on maven central under the groupId io.github.rzo1.org.metatype.sxc. I integrated this new SXC release in a PR [3] and would highly appreciate if we can get some eyes from long time contributors on this. I think there are 3 topics that require attention: 1. Do we want to switch to Richards fork? Maybe we could merge with the original code from David and release that again, though it seems the metatype.org domain is expired and owned by a parking service. We likely can't fork it in tomee as the code is not fully under the Apache 2.0 License. 2. Some tests were failing after I fully regenerated the SXC accessor classes because the generated code has been modified in some places to allow unknown XML nodes. I recreated this behavior by adding @XmlAnyAttribute annotated fields where needed. We should be double checking that I did not miss anything. 3. (optional) The accessors are 100% matching the JAXB model now. IMO we should highly consider to delete these from the repository and treat them as generated sources. This would remove tens of thousands of lines of code and force future developers to make adjustments in the JAXB Model instead of hiding them in generated code. WDYT? Any feedback would be highly appreciated as this is a pretty significant change. The diff for the PR that regenerates all accessors [3] is 30k+ lines long. Thanks Markus [1] https://github.com/apache/tomee/pull/1458 [2] https://github.com/rzo1/sxc [3] https://github.com/apache/tomee/pull/1469
Classes in openejb-jee
Hey all, I’ve been looking at the concurrency TCK for a bit now and noticed we still have a somewhat large gap to be fully implementing the Concurrency 3.0 spec. One thing that is new in the concurrency 3.0 spec is annotations to define different services (ContextService, ManagedExecutorService, etc) via annotations on beans. I’ve discovered that Jon already implemented this behavior for @ContextServiceDefinition by doing the following: 1. AnnotationDeployer scans beans for @ContextServiceDefinition 2. It creates a ContextService object and stores it in the JndiConsumer 3. ConvertContextServiceDefinitions picks this up and turns it into a real Resource that is added into the AppModule What confuses me is the intermediate step 2, ContextService looks like it is an autogenerated class from some XSD file, but the XSD is nowhere to be found. @Jonathan (or anyone, really), maybe you can shed some light onto this? Me and Richard are suspecting these classes have been generated back in the EE6 days (looking at the XSD files) and modified as needed ever since. Thanks Markus
Re: TomEE 10 & TCK
gt; [4] >>> https://download.eclipse.org/jakartaee/jsonp/2.1/jakarta-jsonp-tck-2.1.0.zip >>> >>> >>> [5] >>> https://download.eclipse.org/jakartaee/restful-ws/3.1/jakarta-restful-ws-tck-3.1.0.zip >>> >>> >>> [6] >>> https://download.eclipse.org/jakartaee/security/3.0/jakarta-security-tck-3.0.0.zip >>> >>> >>> [7] >>> https://download.eclipse.org/jakartaee/authentication/3.0/jakarta-authentication-tck-3.0.2.zip >>> >>> >>> [8] https://download.eclipse.org/jakartaee/cdi/4.0/cdi-tck-4.0.5-dist.zip >>> >>> [9] >>> https://download.eclipse.org/jakartaee/bean-validation/3.0/beanvalidation-tck-dist-3.0.1.zip >>> >>> >>> [10] >>> https://download.eclipse.org/jakartaee/dependency-injection/2.0/jakarta.inject-tck-2.0.2-bin.zip >>> >>> >>> [11] >>> https://download.eclipse.org/jakartaee/debugging/2.0/jakarta-debugging-tck-2.0.0.zip >>> >>> >>> [12] https://tomee.apache.org/9.0.0-M7/plume/webprofile-9.1.html >>> >>> [13] >>> https://jakarta.ee/specifications/webprofile/10/jakarta-webprofile-spec-10.0#a43 >>> >>> >>> >>> >>> >>> >>> Em qui, 25 jul 2024 02:38:32 -0300 Richard Zowalla >>> <mailto:r...@apache.org> escreveu --- >>> >>> >>> >>> Hi David, >>> >>> Thanks for clarification! >>> >>> Gruß >>> Richard >>> >>>> Am 25.07.2024 um 00:39 schrieb David Blevins >>>> <mailto:mailto:david.blev...@gmail.com>: >>>> >>>> Hey All, >>>> >>>> We do need to still run and pass the Web Profile tests of the Platform >>>> TCK. More tests have been broken out in the same fashion CDI and >>>> Validation were always broken out, but there are still a great deal of >>>> tests that are not broken out and unlikely to ever be -- connector, ejb >>>> and certain integration tests in particular. >>>> >>>> Here is a certification result that includes tests from the Platform TCK >>>> and the name, version and SHA of the TCK binary used: >>>> >>>> - >>>> https://glassfish.org/certifications/jakarta-platform/10/TCK-Results-7.0.0-M8 >>>> >>>> >>>> Those can be found from this page: >>>> >>>> - https://jakarta.ee/compatibility/certification/10/ >>>> >>>> >>>> -David >>>> >>>>> On Jul 23, 2024, at 12:05 PM, Richard Zowalla >>>>> <mailto:mailto:r...@apache.org> wrote: >>>>> >>>>> Hey guys, >>>>> >>>>> do we actually need to run the platform-tck? >>>>> >>>>> Markus and myself were looking into it and for example Payara and Wildly >>>>> are doing standalone setups only: >>>>> >>>>> - https://github.com/payara/jakartaee-10-tck-runners >>>>> - https://github.com/wildfly/wildfly-tck-runners/tree/wildfly-27 >>>>> >>>>> So do we actually need the javatest based setup at all(aka platform-tck) >>>>> ?? >>>>> >>>>> Or can we also just do a bunch of standalone tck setups (as we already to >>>>> in /tck in the TomEE repo) and claim to be compliant if we pass the set >>>>> needed for the web profile? >>>>> >>>>> Hoping for someone, who is more familiar with the certification process >>>>> (David, maybe??) to jump in to give some guidance? >>>>> >>>>> Gruß >>>>> Richard >>>>> >>>>> >>>>>> Am 23.07.2024 um 12:53 schrieb Jonathan Gallimore >>>>>> <mailto:mailto:jonathan.gallim...@gmail.com>: >>>>>> >>>>>>> Also I'm far away from doing a complete run, I only ran a couple dozen >>>>>>> tests so far. Ideally once we figure out these setup issues someone >>>>>>> from >>>>>>> tomitribe could trigger a full run on tck.work so we can get some >>>>>>> actual >>>>>>> numbers. >>>>>> >>>>>> I'm happy to help wire that up. >>>>>> >>>>
Re: TomEE 10 & TCK
Hey Richard, I did some initial work on running a few TCK tests in the platform-tck the past days and have been able to gain some quick wins with a couple of setup issues. [1] This is where I'm at: Main pain points are that LegacyCookieProcessor is gone in Tomcat 10.1 which causes a bunch of tests to fail and tssv.jar is seemingly missing from the platform-tck, which makes the ProviderConfiguration [2] invalid as this .jar contains the class com.sun.ts.tests.jaspic.tssv.config.TSAuthConfigProvider. Updating the Context.xml configs to not reference LegacyCookieProcesor anymore did the trick but I'm still trying to figure out what needs to be done to get the tssv.jar file. It was in the EE 9.1 TCK but is seemingly missing from EE 10. One solution that works is just extracting it from the Authentication 3.0 TCK, but I doubt this is the right solution. Maybe someone who is more involved knows more? Also I'm far away from doing a complete run, I only ran a couple dozen tests so far. Ideally once we figure out these setup issues someone from tomitribe could trigger a full run on tck.work so we can get some actual numbers. Thanks Markus [1] https://github.com/jungm/tomee-tck/tree/ee10work [2] https://github.com/jungm/tomee-tck/blob/main/src/test/tomee-plume/conf/ProviderConfiguration.xml On 23.07.24 11:06, Richard Zowalla wrote: Hi all, TomEE 10.0.0-M2 is out and it seems, that we have quite a few people already testing it, which is great. Since we resolved most of the open dependency updates related to EE10, we can now start to work on TCK setup / compliance or at least to get some numbers. Aside from the standalone TCKs here [1], we will need to check on how to run https://github.com/jakartaee/platform-tck/tree/10.0.x with TomEE 10 to (at least) get some numbers. Some of the required tweaks / config options (etc) can be found here: https://github.com/apache/tomee-tck I think, that Markus J. did a quick check on the platform-tck, so maybe you can add your findings in this thread, so we can (hopefully) create an environment for further discussion on how to proceed with the TCK itself. From what I remember on the standalone TCKs: - We need to correctly setup the concurrency TCK and fix our implementation if needed. - We need to check on the CDI TCK. All TCKs can be enabled via a specific Maven profile. There are still some other open things: - MP 6.0 requires us to implement OpenTelemetry, which hangs because of https://issues.apache.org/jira/browse/OWB-1441 atm. - CXF 4.1.0 needs to be final ;-) So if anyone wants to have a look into one of these areas, feel free to drop a message on dev@ Cheers, Richard [1] https://github.com/apache/tomee/tree/main/tck
Re: [VOTE] TomEE 10.0.0-M2
+1 (non binding) I tested a couple of real applications (running on Linux, Java 17) using: - CDI - Faces - JPA (running hibernate 6.4) - Security (Both custom HttpAuthenticationMechanism and new OpenIdAuthenticationMechanismDefinition) - JSON-B/JSON-P - tomee-embedded-maven-plugin and standalone tomee-micorprofile - microprofile OpenAPI, Config, Health Awesome work, thanks to everyone involved! On 16.07.24 10:04, Richard Zowalla wrote: Hello everyone, This is a vote for the release of Apache TomEE 10.0.0-M2. This is the second milestone release of TomEE 10 targeting JakartaEE 10. Thanks to everyone who contributed code to make this happen. I would like to emphasise and give a shout out to all our volunteers who have been doing the hard work for EE10, which is also being done in all our upstream upstream dependencies such as Tomcat, OWB, CXF, MyFaces, etc. Notable changes: - This is the first TomEE 10 release to require Java 17 at runtime (due to CXF and ActiveMQ). - We are now implementing the OIDC part of the EE Security Spec and passing the corresponding part of the TCK (thanks to Markus Jung). - We have integrated some updates in the MicroProfile area (not complete) and passed the related TCKs. - It is based on a fork of CXF 4.1.0-SNAPSHOT, see https://issues.apache.org/jira/browse/TOMEE-4353 for details. We pass most of the JAX-RS TCK here. - Fixes some bugs and quirks like broken Mojarra (due to CDI spec ambiguity) and others. Please note that we do not pass the full EE TCK, nor do we have a fully functional TCK setup at the at the moment. However, our own full build is green and so I am happy to to call for a vote to release a second milestone of TomEE 10. Here are the hard facts: ### Maven Repo: https://repository.apache.org/content/repositories/orgapachetomee-1228/ tomee-10.0.0-M2-rc1 Testing TomEE 10.0.0-M2 https://repository.apache.org/content/repositories/orgapachetomee-1228/ ### Binaries & Source: https://dist.apache.org/repos/dist/dev/tomee/staging-1228/tomee-10.0.0-M2/ ### Tag: https://github.com/apache/tomee/releases/tag/tomee-project-10.0.0-M2 ### Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12354473 ### Here is an adoc generated version of the changelog as well: == Dependency upgrade [.compact] - link:https://issues.apache.org/jira/browse/TOMEE-4337[TOMEE-4337] bcprov-jdk15to18-1.76.jar and bcpkix-jdk15to18-1.76.jar - link:https://issues.apache.org/jira/browse/TOMEE-4317[TOMEE-4317] ActiveMQ 6.1.0 - link:https://issues.apache.org/jira/browse/TOMEE-4359[TOMEE-4359] ActiveMQ 6.1.2 - link:https://issues.apache.org/jira/browse/TOMEE-4341[TOMEE-4341] Angus Activation 2.0.2 - link:https://issues.apache.org/jira/browse/TOMEE-4362[TOMEE-4362] Commons IO 2.16.1 - link:https://issues.apache.org/jira/browse/TOMEE-4346[TOMEE-4346] Commons Lang 3.14.0 - link:https://issues.apache.org/jira/browse/TOMEE-4345[TOMEE-4345] Commons Logging 1.3.2 - link:https://issues.apache.org/jira/browse/TOMEE-4339[TOMEE-4339] Compress 1.16.0 - link:https://issues.apache.org/jira/browse/TOMEE-4363[TOMEE-4363] DBCP 2.12.0 - link:https://issues.apache.org/jira/browse/TOMEE-4364[TOMEE-4364] Downgrade Mojarra 4.0.0 (cf. TOMEE-4355) - link:https://issues.apache.org/jira/browse/TOMEE-4349[TOMEE-4349] ECJ 3.37.0 - link:https://issues.apache.org/jira/browse/TOMEE-4360[TOMEE-4360] ECJ 3.38.0 - link:https://issues.apache.org/jira/browse/TOMEE-4365[TOMEE-4365] EclipseLink 4.0.3 - link:https://issues.apache.org/jira/browse/TOMEE-4369[TOMEE-4369] HSQLDB 2.7.3 - link:https://issues.apache.org/jira/browse/TOMEE-4367[TOMEE-4367] Hibernate Validator 8.0.1.Final - link:https://issues.apache.org/jira/browse/TOMEE-4361[TOMEE-4361] Jackson 2.17.2 - link:https://issues.apache.org/jira/browse/TOMEE-4335[TOMEE-4335] Jetty 11.0.20 - link:https://issues.apache.org/jira/browse/TOMEE-4340[TOMEE-4340] Jose JWT 9.39.1 (Test) - link:https://issues.apache.org/jira/browse/TOMEE-4113[TOMEE-4113] MP Metrics 5 / SmallRye Metrics 5 - link:https://issues.apache.org/jira/browse/TOMEE-4356[TOMEE-4356] Mojarra 4.0.7 - link:https://issues.apache.org/jira/browse/TOMEE-4348[TOMEE-4348] Smallrye Config 3.8.2 - link:https://issues.apache.org/jira/browse/TOMEE-4353[TOMEE-4353] Temporarily switch CXF 4.1.0 fork version have a stable version for a possible TomEE 10-M2 release. - link:https://issues.apache.org/jira/browse/TOMEE-4328[TOMEE-4328] TomEE 10.1.23 - link:https://issues.apache.org/jira/browse/TOMEE-4334[TOMEE-4334] Tomcat 10.1.24 - link:https://issues.apache.org/jira/browse/TOMEE-4352[TOMEE-4352] Tomcat 10.1.25 - link:https://issues.apache.org/jira/browse/TOMEE-4326[TOMEE-4326] XBeans 4.25 - link:https://issues.apache.org/jira/browse/TOMEE-4338[TOMEE-4338] Xalan 2.7.3 == New Feature [.compact] - li
Re: [DISCUSS] TomEE 10.0.0-M2
Hey Richard, no strong opinion for (1) from my side, if there are no objections we should just merge it so we can push another milestone release IMO. +1 to downgrade Mojarra to 4.0.0 to make tomee-plume usable again until we figure out where and how to fix Mojarra 4.0.1+ integration with OWB. Generally huge +1 to release M2 Thanks Markus On 08.07.24 10:43, Richard Zowalla wrote: Hi all, We had quite a few fixes and dependency updates since we released M1 (like Java 17 baseline, ams, cxc, mp updates), see https://issues.apache.org/jira/projects/TOMEE/versions/12354473 Currently, we have two open things, we need to discuss (1) https://github.com/apache/tomee/pull/1229 (2) https://issues.apache.org/jira/browse/TOMEE-4355 Regarding - (1): Are there any objections (ping @PMC) in temporary integrating my CXF fork until CXF has a stable release? If I do not hear back on this matter, I will assume lazy consensus. - (2): This is a bit more difficult because it boils down to spec / ambiguity and discussion. See the issue and linked OWB for details. I don’t think it is a blocker for M2 (as it can be solved by downgrading to Mojarra 4.0.0, which doesn’t have the changes). I would suggest, that we downgrade Mojarra for a potential M2 release to avoid surprises until it is resolved either in TomEE, OWB or Mojarra. Any other thoughts? Gruß Richard
Re: AutoConfig undeclared dependencies in Resources?
Hey all, took a look at the Concurrency 3.0 spec - it states: The Jakarta EE Product Provider must provide a preconfigured, default ContextService for use by application components under the JNDI name java:comp/DefaultContextService IMO considering this it makes sense to automatically resolve a ContextService if a user does not explicitly overwrite it. Also makes moving from TomEE 9 to TomEE 10 easier. Any more thoughts on this? Thanks Markus On 03.07.24 20:48, Richard Zowalla wrote: Hi all, I want to add some additional thoughts here: The question is more or less a question related to the original design of the auto configuration of TomEE, so basically boils down to: Should a default context service be created if implicitly referenced by a user-defined custom managed (or scheduled) executor service or not. Nevertheless, the current behavior is odd, so the end user doesn’t actually know what is going on. Regardless of which path we choose, we need to update the related documentation to state, that a context service is (now) needed. For people migrating from older version of TomEE, it would be more than neat to automatically create and configure the default context service to smooth transitions to TomEE 10. Wdyt? Gruß Richard Am 03.07.2024 um 12:57 schrieb Markus Jung: Hey all, I've been investigating an issue a user reported with 10.0.0-M1 [1] with Richard yesterday. The user configured a ManagedExecutorService Resource but omitted configuring a ContextService (which is required in TomEE 10). This causes the ManagedExecutorService to default to the "Default Context Service" ContextService, which doesn't get configured automatically because it is not injected anywhere. This leads to an ambiguous exception that "Default Context Service" is unknown. If everything is configured (ManagedExecutorService + ContextService) and linked together it works. If nothing is configured it works as well (ContextService gets auto configured when ManagedExecutorService is auto configured). However Configurations that were valid in TomEE 9 as the one reported in [1] are now invalid. I'm not sure how this is actually intended to be used, documentation for ManagedExecutorService is outdated as it doesn't mention the requirement of a ContextService yet. Should it work and the ContextService gets auto configured if not explicitly configured? Or fail and tell the user in a more understandable way that requirements have not been met? Thanks Markus [1]https://issues.apache.org/jira/browse/TOMEE-4354
AutoConfig undeclared dependencies in Resources?
Hey all, I've been investigating an issue a user reported with 10.0.0-M1 [1] with Richard yesterday. The user configured a ManagedExecutorService Resource but omitted configuring a ContextService (which is required in TomEE 10). This causes the ManagedExecutorService to default to the "Default Context Service" ContextService, which doesn't get configured automatically because it is not injected anywhere. This leads to an ambiguous exception that "Default Context Service" is unknown. If everything is configured (ManagedExecutorService + ContextService) and linked together it works. If nothing is configured it works as well (ContextService gets auto configured when ManagedExecutorService is auto configured). However Configurations that were valid in TomEE 9 as the one reported in [1] are now invalid. I'm not sure how this is actually intended to be used, documentation for ManagedExecutorService is outdated as it doesn't mention the requirement of a ContextService yet. Should it work and the ContextService gets auto configured if not explicitly configured? Or fail and tell the user in a more understandable way that requirements have not been met? Thanks Markus [1] https://issues.apache.org/jira/browse/TOMEE-4354
Re: CXF 4.1.0 Fork Release - Thoughts?
Another quick thought I had: This will break builds for users of the tomee BOMs that rely on CXF. This would've also been the case with any of the approaches to solve this. But IMHO this isn't as big of a problem right now, we're still in the stage of pretty early milestones of a new major release anyways and stuff breaking is somewhat to be expected ;) Awesome work! On 01.07.24 15:59, Richard Zowalla wrote: Hi all, managed to deploy my fork to central. Here is the PR: https://github.com/apache/tomee/pull/1229 (REST) TCK is still fine. Gruß Richard On 2024/07/01 08:49:41 Richard Zowalla wrote: Copying the whole bunch of code into TomEE doesn’t look like a good idea (imho). I just tested putting packages up on GitHub registry but this has the limitation, that people (and CI) need additional authentication (but it is a proof, that it would work basically) Don’t know what is currently needed to put something directly on Maven Central (would need to do some research) but I think, that it might be quite a lot of work for a one time thing or does someone have experience in that area (the process changed a few weeks ago) ? Am 01.07.2024 um 08:55 schrieb Markus Jung : Hey Richard, IMO there's 3 possible solutions to handle this. I've ordered these in what I believe is the amount of effort required to set up: 1. Copy CXF sources into TomEE sources so we can simply release it with the next milestone 2. Release current CXF snapshot outside of the ASF and use it as a dependency 3. Formally create a tomee subproject, put CXF sources there, release and use it Simply copying CXF sources into the tomee project (and deleting them later on once we got official 4.1 artifacts) is super quick and simple, but I'm really not sure if this is something we should be doing. Releasing CXF somewhere else can be pretty easy but it requires some more work to set things up and deploy the release to some Maven repository. (GitHub artifacts? Maven Central?) Setting up a tomee subproject is probably pretty much the same effort but it means we need to adhere to the ASF release process, do a formal vote etc. Also not sure how easily such a subproject can be abandoned again once CXF 4.1 arrives and we don't need this setup anymore. IMHO both solutions 1 and 2 are quick and desirable, though 1 would really need to be discussed. 3 requires at least a couple of people to be involved to do a formal vote. Any other thoughts on this? Thanks Markus On 27.06.24 15:34, Richard Zowalla wrote: Hi all, I just forked CXF (from the latest green build with 7ab74899002f69055175dacae946b7664413c9ad) on my personal repo and did a search / replace party for the group id from org.apache.cxf to org.apache.tomee.cxf [1] Of course it would need to be moved in a tomee-related repo. The build works fine locally. How shall we proceed with it? Do we need to run a formal vote to release a milestone maven artifact under our own group id (with all the necessities such as providing the source code via svn) or is it sufficient to do this for maven only (and vote regardless). Other possibility would be to release outside of the ASF umbrella and add that as dependency. Thoughts? Gruß Richard [1] https://github.com/rzo1/cxf/tree/cxf-4.1.0-tomee
Re: CXF 4.1.0 Fork Release - Thoughts?
Hey Richard, IMO there's 3 possible solutions to handle this. I've ordered these in what I believe is the amount of effort required to set up: 1. Copy CXF sources into TomEE sources so we can simply release it with the next milestone 2. Release current CXF snapshot outside of the ASF and use it as a dependency 3. Formally create a tomee subproject, put CXF sources there, release and use it Simply copying CXF sources into the tomee project (and deleting them later on once we got official 4.1 artifacts) is super quick and simple, but I'm really not sure if this is something we should be doing. Releasing CXF somewhere else can be pretty easy but it requires some more work to set things up and deploy the release to some Maven repository. (GitHub artifacts? Maven Central?) Setting up a tomee subproject is probably pretty much the same effort but it means we need to adhere to the ASF release process, do a formal vote etc. Also not sure how easily such a subproject can be abandoned again once CXF 4.1 arrives and we don't need this setup anymore. IMHO both solutions 1 and 2 are quick and desirable, though 1 would really need to be discussed. 3 requires at least a couple of people to be involved to do a formal vote. Any other thoughts on this? Thanks Markus On 27.06.24 15:34, Richard Zowalla wrote: Hi all, I just forked CXF (from the latest green build with 7ab74899002f69055175dacae946b7664413c9ad) on my personal repo and did a search / replace party for the group id from org.apache.cxf to org.apache.tomee.cxf [1] Of course it would need to be moved in a tomee-related repo. The build works fine locally. How shall we proceed with it? Do we need to run a formal vote to release a milestone maven artifact under our own group id (with all the necessities such as providing the source code via svn) or is it sufficient to do this for maven only (and vote regardless). Other possibility would be to release outside of the ASF umbrella and add that as dependency. Thoughts? Gruß Richard [1] https://github.com/rzo1/cxf/tree/cxf-4.1.0-tomee
Re: Update on TomEE 10
Hey Richard, huge +1 from my side for an M2 when my OIDC PR is merged, that would allow us to become the first real user of this feature ASAP and probably provide some more feedback and patches ;) Don't know how likely a CXF 4.1.0 release/milestone is in the near future, I'm fine if we downgrade again for now. However, my OIDC code already uses some language features not available in Java 11. So I think we need to keep Java 17 as a requirement. Thanks Markus > On 12. Jun 2024, at 06:17, Richard Zowalla wrote: > > Hi all, > > Here is a new update on TomEE 10. > > Markus Jung has implemented the missing part of the EE10 security spec: [1] > and the TCK for it looks good. Thanks a lot for that contribution! If anybody > wants to give it a review, you find it here: [1] > > We have updated most MicroProfile specs to be compliant with MP6 and the TCK > for it looks good. > > The only MicroProfile implementation missing is OpenTelemetry 1.0 [2] (and > the removal of OpenTracing). There is a branch with a basic integration > (TOMEE-4343) but while working on it, I found something odd, which I did > discuss with Romain via Slack. The result is [3]. I hope to get some > additional input from Mark Struberg on it, so we can hopefully find a way to > fix the odd CDI part here. Overall, the related TCK has around 4-5 which are > (most likely) a result of [3] because the interceptor is not working as > expected. > > Since we are more and more in a (better) EE10 shape, we need to go back into > fixing/adding the existing/remaining TCKs inside the TomEE build to see, if > we need to do some work in our upstream dependencies. I am planning to send > an update for that area soon, so we get an overview of what is already added > and what is broken / missing, > > We are blocked by a release of CXF 4.1.0-SNAPSHOT. > > We should (imho) discuss, if it is worth to release a M2 with a downgrade to > the latest stable CXF release since we added new features (MicroProfile > updates, potentially OIDC soon) and upgraded a lot of 3rd party CVEs. So from > my POV it would be crucial to get some feedback on a new milestone release. > WDYT? > > Gruß > Richard > > [1] https://github.com/apache/tomee/pull/1178 > [2] https://issues.apache.org/jira/browse/TOMEE-4343 > [1] https://issues.apache.org/jira/browse/OWB-1441
Re: EE10 - Jakarta Security OIDC
Hi David,
I can absolutely understand that this is a bit much to ask for to
review. I think this is what really needs a closer look and maybe needs
to be discussed:
- JWT Validation is using jose.4.j, this introduces a new dependency in
all tomee flavours (wasn't in webprofile before). Maybe it needs to be
added in some notice file?
- Spec mentions a special variable that can be used in the annotation:
${baseURL}, I implemented this with producing an @Named String
- I built a basic delegate in
OpenIdAuthenticationMechanismDefinitionDelegate that automatically
resolves the configuration from the openid provider
- SavedRequest (originally from @LoginToContinue) has been rewritten so
I can serialize it for use in cookies
- Spec is ambiguous on how to handle subjectTypeSupported,
idTokenSigningAlgorithmsSupported and responseTypeSupported (See
CompositeOpenIdProviderMetadata). A user can override these, but it's
not obvious if that has been done or not. I handled these the same way
soteria does, but it's probably worth a spec issue in the future?
- Requests to openid provider are done using JAX-RS Client, maybe we
want to use something else in TomEE? Really the only reason I chose this
was because it's convenient
I appreciate any feedback, will also put this bullet point list in the
PR so it gets some visibility there. The PR is already pretty big so I'm
on your side to merge if it doesn't break anything, reviewing this just
gets harder and harder with every commit I add.
Thanks
Markus
On 12.06.24 00:36, David Blevins wrote:
Are there specific parts you'd like eyes on? Maybe some things you imaged
could be done a few different ways and chose one hoping for feedback if it
wasn't right? Perhaps any new deployment or runtime concepts that were added?
-David
On Jun 11, 2024, at 3:33 PM, David Blevins wrote:
I've only had a change to take a cursory look at the PR, but I was immediately
impressed.
I can't thank you enough -- what an amazing undertaking!
It might be crickets getting a review for a PR that big especially given our
starved state, so as long as you're a good sport about changes to the code
after it's merged I suspect we should just merge it and see what breaks.
Totally ok to leave it open for a bit as well.
What an amazing contribution, Markus. Seriously. Huge applause.
-David
On Jun 2, 2024, at 8:34 AM, Markus Jung wrote:
Hi all,
small update after a long time of silence, my implementation now passes the
(admittedly very few) openid tests in the TCK:
[INFO] Reactor Summary for Jakarta Security TCK - main 3.0.1:
[INFO]
[INFO] Jakarta Security TCK - main SUCCESS [ 2.725 s]
[INFO] common . SUCCESS [ 0.748 s]
[INFO] app-openid . SUCCESS [ 6.556 s]
[INFO] app-openid2 SUCCESS [ 15.742 s]
[INFO] app-openid3 SUCCESS [ 14.100 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 39.986 s
[INFO] Finished at: 2024-06-02T17:24:15+02:00
[INFO]
I've opened a pull request in the meantime here
https://github.com/apache/tomee/pull/1178 to gather some feedback, the
implementation is pretty much done IMO.
However I'd like to add more unit/integration tests and clean up the code a bit
more, that's why I'm keeping the PR in draft state for now.
Thanks
Markus
On 20. Apr 2024, at 16:13, Richard Zowalla wrote:
Cool! Thanks, Markus!
Feel free to ask any question you might come across while implementing!
Am Freitag, dem 19.04.2024 um 17:14 +0200 schrieb Markus Jung:
Hey all,
just a quick heads up, i've began trying to work on this a couple of
days ago here: https://github.com/jungm/tomee/tree/openid
It's still a huge work in progress right now though
On 13. Apr 2024, at 20:29, Richard Zowalla wrote:
Hi,
looks like we need to implement OpenID connect for Jakarta Security
3.0
- https://jakarta.ee/specifications/security/3.0/
If anyone wants to jump in and dive into the spec -> feel free :)
Gruß
Richard
Re: EE10 - Jakarta Security OIDC
Hi all, small update after a long time of silence, my implementation now passes the (admittedly very few) openid tests in the TCK: [INFO] Reactor Summary for Jakarta Security TCK - main 3.0.1: [INFO] [INFO] Jakarta Security TCK - main SUCCESS [ 2.725 s] [INFO] common . SUCCESS [ 0.748 s] [INFO] app-openid . SUCCESS [ 6.556 s] [INFO] app-openid2 SUCCESS [ 15.742 s] [INFO] app-openid3 SUCCESS [ 14.100 s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 39.986 s [INFO] Finished at: 2024-06-02T17:24:15+02:00 [INFO] I've opened a pull request in the meantime here https://github.com/apache/tomee/pull/1178 to gather some feedback, the implementation is pretty much done IMO. However I'd like to add more unit/integration tests and clean up the code a bit more, that's why I'm keeping the PR in draft state for now. Thanks Markus > On 20. Apr 2024, at 16:13, Richard Zowalla wrote: > > Cool! Thanks, Markus! > Feel free to ask any question you might come across while implementing! > > Am Freitag, dem 19.04.2024 um 17:14 +0200 schrieb Markus Jung: >> Hey all, >> >> just a quick heads up, i've began trying to work on this a couple of >> days ago here: https://github.com/jungm/tomee/tree/openid >> >> It's still a huge work in progress right now though >> >> >>> On 13. Apr 2024, at 20:29, Richard Zowalla wrote: >>> >>> Hi, >>> >>> looks like we need to implement OpenID connect for Jakarta Security >>> 3.0 >>> >>> - https://jakarta.ee/specifications/security/3.0/ >>> >>> If anyone wants to jump in and dive into the spec -> feel free :) >>> >>> Gruß >>> Richard >> >
Re: EE10 - Jakarta Security OIDC
Hey all, just a quick heads up, i've began trying to work on this a couple of days ago here: https://github.com/jungm/tomee/tree/openid It's still a huge work in progress right now though > On 13. Apr 2024, at 20:29, Richard Zowalla wrote: > > Hi, > > looks like we need to implement OpenID connect for Jakarta Security 3.0 > > - https://jakarta.ee/specifications/security/3.0/ > > If anyone wants to jump in and dive into the spec -> feel free :) > > Gruß > Richard
[DISCUSS] Drop TomEE 8.x docker images?
Hi all, I just opened a PR to add TomEE 10.0.0-M1 Dockerfiles [1], we're now at 80 different variants of docker images being built for tomee: $ find . -name Dockerfile | wc -l 80 In the future this number could increase even more when we add docker images based on Java 21. (Depending on if we continue support for Java 11 [2]) IMO we should drop Dockerfiles for TomEE 8.x, it's EOL and there really is no need to continue building docker images for it. WDYT? Thanks Markus [1] https://github.com/tomitribe/docker-tomee/pull/89 [2] https://lists.apache.org/thread/4qox0vtoyv535w8cfkfqbx8swz95000q
Re: [DISCUSS] Switch "main" (TomEE 10) to Java 17 ?
+1 from my side as well, IMO having an EE10 compatible (but non compliant) TomEE 10 is more desirable than not having a full implementation of EE10 specs at all On 05.04.24 17:21, Jonathan S. Fisher wrote: I'm good with JDK17! Just don't skip ahead to 21 LTS [required] yet, I think it's healthy to lag behind one LTS edition. On Fri, Apr 5, 2024 at 9:24 AM Thomas Andraschko wrote: +1 for Java17 seems we have no other choice maybe we can try to get certified on Java17 but we still need green TCKs first anyway, which is not reachable without Java17 right now. Am Fr., 5. Apr. 2024 um 16:00 Uhr schrieb Richard Zowalla : Hello everyone, We should discuss the following to get up to speed on our EE-10 efforts. For EE-10 we need - JMS 3.1 [1] - JAX-RS 3.1 [2] AMQ-6 (which will become JMS 3) has changed it's baseline to Java 17 [3]. CXF 4.1.0-SNAPSHOT (which will target JAX-RS 3.1) has switched it's baseline to Java 17 [4]. From my understanding of the EE10 specification, we would have to pass the TCK with Java 11 and Java 17 to be "certified". With CXF 4.1 going to Java 17 as a baseline, we won't be able to run the TCK on a Java 11 setup, making it impossible to get "certified" (as far as I understand the requirements from the TCK/EE platform spec). We can still work on the TCK setup and get as many green tests as we want to gain more confidence in our work/implementation and gain experience in setup etc. Therefore, I would like to discuss the following - Do we have any other option than to change our baseline to 17 for TomEE 10 as well? From my point of view, we should make this change (baseline to 17), bite the bad apple of no longer being able to get certified with it, and get a final TomEE 10 soon so we can look at the upcoming EE-11. Wdyt? Gruß Ricahrd [1] https://jakarta.ee/specifications/messaging/3.1/ [2] https://jakarta.ee/specifications/restful-ws/3.1/ [3] https://lists.apache.org/thread/gjmhcj4frqp9x00cg5kylvy4s1lys7z6 [4] https://github.com/apache/cxf/commit/e8cd5e904419cfd21437db6bfb0e7b309c575715
Re: AW: [VOTE] Apache TomEE 10.0.0-M1
+1 (non binding) Did some testing with our real apps (Java 17, GNU/Linux x86-64), including: - CDI - JSF - JPA (using hibernate 6.4) - Jakarta Security (custom HttpAuthenticationMechanism) - JSON-P/JSON-B - Microprofile: OpenAPI, Config, Health - tomee-embedded-maven-plugin and tomee-microprofile standalone Everything looks good, awesome work! On 02.04.24 14:45, Frank Jung wrote: +1 Thank you! Frankie -Ursprüngliche Nachricht- Von: Richard Zowalla Gesendet: Dienstag, 2. April 2024 09:47 An: dev@tomee.apache.org Betreff: [VOTE] Apache TomEE 10.0.0-M1 Hello everyone, This is a vote for the release of Apache TomEE 10.0.0-M1. It is a first milestone release of TomEE 10 targeting JakartaEE 10. Thanks to everyone who contributed code to make this happen. I would like to emphasise and give a shout out to all our volunteers who have done the hard work for EE10, which is also done in all our upstream dependencies like Tomcat, OWB, CXF, MyFaces, etc. This milestone release is not fully compliant with JakartaEE 10 as we are missing some EE10 compatible versions of our dependencies (most notably CXF 4.1.x which isn't available yet). We do not pass the TCK, nor do we have a fully working TCK setup at the moment. However, our own full build is green [1] and so I am happy to call for a vote to release a first milestone of TomEE 10. Here are the hard facts: ### Maven Repo: https://repository.apache.org/content/repositories/orgapachetomee-1226/ tomee-10.0.0-M1-rc1 Testing TomEE 10.0.0-M1 https://repository.apache.org/content/repositories/orgapachetomee-1226/ ### Binaries & Source: https://dist.apache.org/repos/dist/dev/tomee/staging-1226/tomee-10.0.0- M1/ ### Tag: https://github.com/apache/tomee/releases/tag/tomee-project-10.0.0-M1 ### Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320 &version=12352714 ### Here is an adoc generated version of the changelog as well: == Dependency upgrade [.compact] - link:https://issues.apache.org/jira/browse/TOMEE-4266[TOMEE-4266] ActiveMQ 5.16.7 / 5.18.3 - link:https://issues.apache.org/jira/browse/TOMEE-4217[TOMEE-4217] Arquillian 1.7.0.Final - link:https://issues.apache.org/jira/browse/TOMEE-4307[TOMEE-4307] BatchEE 1.0.4 - link:https://issues.apache.org/jira/browse/TOMEE-4235[TOMEE-4235] Bouncy Castle 1.75 - link:https://issues.apache.org/jira/browse/TOMEE-4243[TOMEE-4243] Bouncy Castle 1.76 - link:https://issues.apache.org/jira/browse/TOMEE-4278[TOMEE-4278] Commons CLI 1.6.0 - link:https://issues.apache.org/jira/browse/TOMEE-4277[TOMEE-4277] Commons Codec 1.16.0 - link:https://issues.apache.org/jira/browse/TOMEE-4274[TOMEE-4274] Commons DBCP 2.11.0 - link:https://issues.apache.org/jira/browse/TOMEE-4275[TOMEE-4275] Commons Lang3 3.13.0 - link:https://issues.apache.org/jira/browse/TOMEE-4310[TOMEE-4310] Commons Net 3.9.0 - link:https://issues.apache.org/jira/browse/TOMEE-4308[TOMEE-4308] Fileupload 2 (Jakarta - link:https://issues.apache.org/jira/browse/TOMEE-4218[TOMEE-4218] HSQLDB 2.7.2 - link:https://issues.apache.org/jira/browse/TOMEE-4221[TOMEE-4221] JUnit 5.9.3 - link:https://issues.apache.org/jira/browse/TOMEE-4212[TOMEE-4212] Jackson 2.15.0 - link:https://issues.apache.org/jira/browse/TOMEE-4216[TOMEE-4216] Jackson 2.15.1 - link:https://issues.apache.org/jira/browse/TOMEE-4227[TOMEE-4227] Jackson 2.15.2 - link:https://issues.apache.org/jira/browse/TOMEE-4276[TOMEE-4276] Jackson 2.15.3 - link:https://issues.apache.org/jira/browse/TOMEE-4208[TOMEE-4208] Johnzon 1.2.20 - link:https://issues.apache.org/jira/browse/TOMEE-4228[TOMEE-4228] Johnzon 1.2.21 - link:https://issues.apache.org/jira/browse/TOMEE-4205[TOMEE-4205] Jose4j 0.9.3 - link:https://issues.apache.org/jira/browse/TOMEE-4279[TOMEE-4279] Log4J2 2.21.1 - link:https://issues.apache.org/jira/browse/TOMEE-4296[TOMEE-4296] MicroProfile JWT 2.1 - link:https://issues.apache.org/jira/browse/TOMEE-4283[TOMEE-4283] OWB 4.0.1 - link:https://issues.apache.org/jira/browse/TOMEE-4282[TOMEE-4282] Tomcat 10.1.16 - link:https://issues.apache.org/jira/browse/TOMEE-4309[TOMEE-4309] Tomcat 10.1.20 - link:https://issues.apache.org/jira/browse/TOMEE-4280[TOMEE-4280] WSS4J 3.0.2 - link:https://issues.apache.org/jira/browse/TOMEE-4313[TOMEE-4313] XBean 4.24 - link:https://issues.apache.org/jira/browse/TOMEE-4232[TOMEE-4232] bcprov-jdk15to18-1.74.jar - link:https://issues.apache.org/jira/browse/TOMEE-4220[TOMEE-4220] log4j 2.20.0 (integration) - link:https://issues.apache.org/jira/browse/TOMEE-4311[TOMEE-4311] log4j2 2.23.1 - link:https://issues.apache.org/jira/browse/TOMEE-4312[TOMEE-4312] slf4j 2.0.12 - link:https://issues.apache.org/jira/browse/TOMEE-4213[TOMEE-4213] snakeyaml version 2.0 mitigate CVE-2022-1471 - link:https://issues.apache.org/jira/browse/TOMEE-4219[TOMEE-4219] xbeans 4.23 == New Feature [.compact] - link:https://
Docker images for TomEE 9.1.2
Hey all, I just opened a PR to get docker images for TomEE 9.1.2 pushed: https://github.com/tomitribe/docker-tomee/pull/88 Would appreciate if anyone can take the time to review and possibly merge. When this is done I'll PR docker-library/official-images as well Thanks! Markus
Re: TomEE 8.0.16 Docker images
Thinking out loud: should we even keep the 7.x Dockerfiles? Continuing to build those causes these tags to show up here https://github.com/docker-library/docs/tree/master/tomee#supported-tags-and-respective-dockerfile-links 7.x (and soon also 8.x) being EOL is exactly the opposite of what docker considers to be supported IMO: https://github.com/docker-library/faq#what-do-you-mean-by-supported Thanks Markus On 07.11.23 21:53, Richard Zowalla wrote: I would update the old images to point to archive.a.o. or Maven - these TomEE versions are eol anyway. Gruß Richard Am 7. November 2023 21:38:23 MEZ schrieb Markus Jung : Hi all, someone know whats going on here? Looks like old tomee builds are no more available at dist.apache.org <http://dist.apache.org/>: https://github.com/docker-library/official-images/pull/15677#issuecomment-1799818513 Looking at https://dist.apache.org/repos/dist/release/tomee/ really there are only builds of the latest 8.x and 9.x versions left, everything else (including current releases) seems to be on https://archive.apache.org/dist/tomee/ now. Is this intended and the Dockerfiles need to be updated? Or perhaps some mistake? Thanks Markus On 7. Nov 2023, at 13:44, Markus Jung wrote: Hey all, I've created a PR in the docker official-images repository to wrap this up https://github.com/docker-library/official-images/pull/15677 Thanks Markus On 06.11.23 15:07, Jean-Louis Monteiro wrote: There is a lot to review if we do line by line, so I reviewed globally and merged. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Nov 6, 2023 at 2:39 PM Jamie Johnson wrote: Believe this is it https://github.com/tomitribe/docker-tomee/pull/84 On Mon, Nov 6, 2023 at 4:46 AM Jean-Louis Monteiro < jlmonte...@tomitribe.com> wrote: Hi Rod, Don't know where your PR is, can you point me in the right direction? I'm happy to review and merge it. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Fri, Nov 3, 2023 at 8:12 PM wrote: All, I have the PR up for the docker images for 8.0.16. They all built and ran in my local environment. If someone approves that PR, I will get it merged and the official images updated. Thanks, Rod.
Re: TomEE 8.0.16 Docker images
Hi all, someone know whats going on here? Looks like old tomee builds are no more available at dist.apache.org <http://dist.apache.org/>: https://github.com/docker-library/official-images/pull/15677#issuecomment-1799818513 Looking at https://dist.apache.org/repos/dist/release/tomee/ really there are only builds of the latest 8.x and 9.x versions left, everything else (including current releases) seems to be on https://archive.apache.org/dist/tomee/ now. Is this intended and the Dockerfiles need to be updated? Or perhaps some mistake? Thanks Markus > On 7. Nov 2023, at 13:44, Markus Jung wrote: > > Hey all, > > I've created a PR in the docker official-images repository to wrap this up > https://github.com/docker-library/official-images/pull/15677 > > > Thanks > > Markus > > On 06.11.23 15:07, Jean-Louis Monteiro wrote: >> There is a lot to review if we do line by line, so I reviewed globally and >> merged. >> -- >> Jean-Louis Monteiro >> http://twitter.com/jlouismonteiro >> http://www.tomitribe.com >> >> >> On Mon, Nov 6, 2023 at 2:39 PM Jamie Johnson wrote: >> >>> Believe this is it >>> >>> https://github.com/tomitribe/docker-tomee/pull/84 >>> >>> >>> On Mon, Nov 6, 2023 at 4:46 AM Jean-Louis Monteiro < >>> jlmonte...@tomitribe.com> >>> wrote: >>> >>>> Hi Rod, >>>> >>>> Don't know where your PR is, can you point me in the right direction? >>>> >>>> I'm happy to review and merge it. >>>> -- >>>> Jean-Louis Monteiro >>>> http://twitter.com/jlouismonteiro >>>> http://www.tomitribe.com >>>> >>>> >>>> On Fri, Nov 3, 2023 at 8:12 PM wrote: >>>> >>>>> All, >>>>> >>>>> >>>>> >>>>> I have the PR up for the docker images for 8.0.16. They all built and >>>> ran >>>>> in my local environment. >>>>> >>>>> >>>>> >>>>> If someone approves that PR, I will get it merged and the official >>> images >>>>> updated. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Rod. >>>>> >>>>> >>>>> >>>>>
Re: TomEE 8.0.16 Docker images
Hey all, I've created a PR in the docker official-images repository to wrap this up https://github.com/docker-library/official-images/pull/15677 Thanks Markus On 06.11.23 15:07, Jean-Louis Monteiro wrote: There is a lot to review if we do line by line, so I reviewed globally and merged. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Nov 6, 2023 at 2:39 PM Jamie Johnson wrote: Believe this is it https://github.com/tomitribe/docker-tomee/pull/84 On Mon, Nov 6, 2023 at 4:46 AM Jean-Louis Monteiro < jlmonte...@tomitribe.com> wrote: Hi Rod, Don't know where your PR is, can you point me in the right direction? I'm happy to review and merge it. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Fri, Nov 3, 2023 at 8:12 PM wrote: All, I have the PR up for the docker images for 8.0.16. They all built and ran in my local environment. If someone approves that PR, I will get it merged and the official images updated. Thanks, Rod.
