+1 for all your proposed steps
Am 13. September 2024 09:15:04 MESZ schrieb Richard Zowalla <r...@apache.org>: >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 <r...@apache.org> wrote: >> > >> > I think, that Markus did some tests. Maybe he can share? :) >> > >> >> Am 09.09.2024 um 09:48 schrieb Jean-Louis Monteiro >> >> <jlmonte...@tomitribe.com>: >> >> >> >> 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 <r...@apache.org> wrote: >> >> >> >>> Any other thoughts? >> >>> >> >>>> Am 05.09.2024 um 11:08 schrieb Richard Zowalla <r...@apache.org>: >> >>>> >> >>>> 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 <ju...@apache.org>: >> >>>>> >> >>>>> 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 >> >>>>>>> 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 >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>> >> >>> >> >>> >> > >> >>
