+1 Richard Zowalla <r...@apache.org> schrieb am Fr., 13. Sept. 2024, 16:15:
> 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 > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> > > >>> > > >>> > > > > > > > >
