You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Markus Jung <ju...@apache.org> on 2024/09/03 11:15:45 UTC
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
Re: SXC Rework
Posted by Markus Jung <ju...@apache.org>.
+1 for all your proposed steps
Am 13. September 2024 09:15:04 MESZ schrieb Richard Zowalla <rz...@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 <rz...@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 <jl...@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 <rz...@apache.org> wrote:
>> >>
>> >>> Any other thoughts?
>> >>>
>> >>>> Am 05.09.2024 um 11:08 schrieb Richard Zowalla <rz...@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 <
>> >>> jungm@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
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>
>> >>>
>> >>>
>> >
>>
>>
Re: SXC Rework
Posted by Thomas Andraschko <an...@gmail.com>.
+1
Richard Zowalla <rz...@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 <rz...@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 <
> jlmonteiro@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 <rz...@apache.org>
> wrote:
> > >>
> > >>> Any other thoughts?
> > >>>
> > >>>> Am 05.09.2024 um 11:08 schrieb Richard Zowalla <rz...@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 <
> > >>> jungm@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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>
> > >>>
> > >>>
> > >
> >
> >
>
Re: SXC Rework
Posted by Richard Zowalla <rz...@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 <rz...@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 <jl...@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 <rz...@apache.org> wrote:
> >>
> >>> Any other thoughts?
> >>>
> >>>> Am 05.09.2024 um 11:08 schrieb Richard Zowalla <rz...@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 <
> >>> jungm@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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>>
> >>>
> >
>
>
Re: SXC Rework
Posted by Markus Jung <ju...@apache.org>.
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 <rz...@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 <jl...@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 <rz...@apache.org> wrote:
>>
>>> Any other thoughts?
>>>
>>>> Am 05.09.2024 um 11:08 schrieb Richard Zowalla <rz...@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 <
>>> jungm@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>>
>
Re: SXC Rework
Posted by Richard Zowalla <rz...@apache.org>.
I think, that Markus did some tests. Maybe he can share? :)
> Am 09.09.2024 um 09:48 schrieb Jean-Louis Monteiro <jl...@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 <rz...@apache.org> wrote:
>
>> Any other thoughts?
>>
>>> Am 05.09.2024 um 11:08 schrieb Richard Zowalla <rz...@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 <
>> jungm@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
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>>
Re: SXC Rework
Posted by Jean-Louis Monteiro <jl...@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 <rz...@apache.org> wrote:
> Any other thoughts?
>
> > Am 05.09.2024 um 11:08 schrieb Richard Zowalla <rz...@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 <
> jungm@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
> >>>>
> >>>>
> >>>>
> >
>
>
Re: SXC Rework
Posted by Richard Zowalla <rz...@apache.org>.
Any other thoughts?
> Am 05.09.2024 um 11:08 schrieb Richard Zowalla <rz...@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
>>>>
>>>>
>>>>
>
Re: SXC Rework
Posted by Richard Zowalla <rz...@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
>>>
>>>
>>>
Re: SXC Rework
Posted by 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
>>
>>
>>
Re: SXC Rework
Posted by Thomas Andraschko <an...@gmail.com>.
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
>
>
>