[CXF-8361] Finalized support for Jakarta NS

[ropalka]

https://issues.apache.org/jira/browse/CXF-8361

• introduced new org.apache.cxf.jaxws.handler.jakarta_types package for JAXB de/serialization
• added new methods in HandlerChainBuilder
• enhanced handlers de/serialization tests

[reta]

Thanks for the PR, @ropalka, I think we got to the point when it is probably make sense to completely separate Jakartaee and Javaee name handler chains (I think you would agree). I suggest to:

1. Introduce org.apache.cxf.jaxws.handler.jakartaee and org.apache.cxf.jaxws.handler.javaee packages
2. Introduce JakartaeeHandlerChainBuilder and JavaeeHandlerChainBuilder
3. Basically, I think it safe to assume that either JakartaEE or JavaEE namespace is going to be used, so in this case AnnotationHandlerChainBuilder could inspect the namespace, instantiate JakartaeeHandlerChainBuilder orJavaeeHandlerChainBuilder, and delegate to one of those. In this case, the conditionals should be gone and implementation becomes much cleaner.

What do you think?

[ropalka]

Hi @reta . It makes sense to me. What I am worry about is backward compatibility.
Isn't jaxws frontend considered to be a public API? In other words if I would refactor package
from org.apache.cxf.jaxws.handler.types to org.apache.cxf.jaxws.handler.javaee
I would break compatibility.

[reta]

Thanks for the reply @ropalka. We won't be changing the public API, which is outlined by AnnotationHandlerChainBuilder. The JakartaeeHandlerChainBuilder and JavaeeHandlerChainBuilder would encapsulate the implementation specifics to each namespace, and are not supposed to be used outside AnnotationHandlerChainBuilder. All the existing classes, under org.apache.cxf.jaxws.handler.types fe, could stay were they are. What do you think?

[ropalka]

Hi @reta . The problem with your proposal is AnnotationHandlerChainBuilder is extending HandlerChainBuilder class.
If I would introduce both JakartaeeHandlerChainBuilder and JavaeeHandlerChain builders I would need to drop
"AnnotationHandlerChainBuilder extends HandlerChainBuilder" relationship which is again not public API backward compatible change. The proposal PR I sent is 100% backward compatible.

[ropalka]

I enhanced this PR to be as much backward compatible as possible @reta.
I introduced new org.apache.cxf.jaxws.handler.jakartaee package as you proposed.
I left org.apache.cxf.jaxws.handler.types package untouched because of BC.
I introduced JAXB deserialization adaptors to be able to eliminate HandlerChainBuilder
'jakartaee' methods I indroduced in previous pull request proposal. WDYT about it now?

[reta]

I enhanced this PR to be as much backward compatible as possible @reta.
I introduced new org.apache.cxf.jaxws.handler.jakartaee package as you proposed.
I left org.apache.cxf.jaxws.handler.types package untouched because of BC.
I introduced JAXB deserialization adaptors to be able to eliminate HandlerChainBuilder
'jakartaee' methods I indroduced in previous pull request proposal. WDYT about it now?

@ropalka thank you for the effort, it definitely looks better but the main problem is still unsolved: the processing of the JavaEE and JakartaEE namespaces is tangled. May I ask you please to take at look at #756, it is based of master (without your changes) but illustrates the idea of how the processing could be separated. AFAIK it does not change or alter any public APIs, only the implementation details have been moved around. Would appreciate to hear any concerns, thank you.

[ropalka]

I updated this PR as you suggested @reta, please review.

[reta]

@ropalka thank you, LGTM, I have a few minor comments which I could address myself if you prefer, otherwise - I think we are good to go

[reta]

Thanks again for your work, @ropalka

[lulseged]

I have tried 3.5.0-SNAPSHOT and miss a lot of jakarta.* packages. When do you plan to move to jakarta namespaces?
The change will not be backward compatible. What is the use of making it backward compatible?
I would create 4.0.0-SNAPSHOT and start jakarta namespace from there and keep 3.x.x javax namespace.

I am getting java.lang.NoClassDefFoundError: javax.annotation.Resource when using 3.5.0-SNAPSHOT.

[reta]

@lulseged please follow #737