> WSS4J only uses the javax.xml.bind dependencies for the streaming implementation, > which is currently only consumed by CXF. CXF won't switch to using Jakarta for a > while, so until then I think there's not much point in updating WSS4J.
CXF is NOT the only consumer of WSS4J and its streaming code. Wildfly and thus EAP use it as do some of its (our) customers. And I would expect there are other products outside the CXF and Wildfly realm that use it as well. In the hierarchy of this ecosystem Santuario is a foundational component. Waiting for higher level components to move before moving this foundational component impedes the progress of all. Why must all be tied to CXF's schedule? Why can't the jakarta native version (e.g. https://github.com/apache/santuario-xml-security-java/pull/63) be provided for those who want to move now? On Mon, Nov 29, 2021 at 6:19 AM Colm O hEigeartaigh <[email protected]> wrote: > We don't have an imminent release date yet, because the Santuario StAX > implementation is really only used by Apache CXF, and CXF confirmed to > me that it would be a while before they switch to using Jakarta. > > Colm. > > On Tue, Nov 23, 2021 at 8:14 PM Rebecca Searls <[email protected]> wrote: > > > > Yes, When will this be available and in a public repository? > > > > On Tue, Nov 23, 2021 at 12:22 PM Colm O hEigeartaigh < > [email protected]> wrote: > >> > >> Hi Rebecca, > >> > >> I believe we have an existing PR - > >> https://github.com/apache/santuario-xml-security-java/pull/63 > >> Or are you referring to something else? > >> > >> Colm. > >> > >> On Tue, Nov 23, 2021 at 1:25 PM Rebecca Searls <[email protected]> > wrote: > >> > > >> > Wildfly components requires a jakarta namesapce version of > org.apache.santuario:xmlsec. > >> > I have created such a version. I would like to submit a PR for it. > >> > >
