Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma]

On Wed, Aug 11, 2021 at 8:26 PM Andriy Redko  wrote:

> Hey Jim, Romain,
>
> Thank you guys, I think Romain's suggestion to move 3.5.x to JDK-11
> baseline is good idea, we would
> still be maintaining 3.4.x for a while, covering JDK-8 based deployments.
> Regarding Jakarta, yes, I
> certainly remember the discussion regarding the build time approach,
> personally with time I came to the
> conclusion that this is not the best option for at least 2 reasons:
>  - differences between source vs binary artifacts are very confusing
> (source imports javax,
>binary has jakarta, or vice versa), I think we all run into that from
> time to time
>  - Jakarta is the way to go, the mainstream should have first class support
>
> Just my 5 cents, but we certainly should consider this approach as well,
> there are good points to
> follow it, summarizing what we have at the moment:
>
> Option #1:
>  - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline
>  - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK
> version (Jetty 10, ...)
>  - branch off 5.x (4.x?) to continue the work on supporting Jakarta 9.0+,
> with JDK-11 as the minimal
>required JDK version (Jetty 11, ...)
>

What's the task for JDK-17 LTS preparation ?  Do we need to support build
3.5.0 with JDK-17 ?

For Jakarta ee9 support branch 4.x with source code change to support
jakarta namespace , we have to wait for spring and other
third party dependencies jakarta ee9 ready.  Now we don't know when these
dependencies are all ready and we can start this work.

Given there is no features added in Jakarta ee 9.1 besides the namespace
change, we can provide the jakarta calssfier maven artifacts and binary
release in 3.6.x or 4.x with transformation or other better approach will
be enough.We provide jakarta ee9 support early, then we can get more
feedback on this topic.




> Option #2:
>  - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline
>  - handle javax by a build setup (with api validation at build time to
> avoid regressions) and use jakarta package as main api in the project
> (Romain), or
>adding a new maven module to transform cxf artifacts with jakarta
> package name (Jim)
>
>  Option #3:
>  - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline
>  - move master to 4.x to continue the work on supporting Jakarta 9.0+,
> with JDK-11 as the minimal
>required JDK version (Jetty 11, ...)
>
> Thank you!
>
> Best Regards,
> Andriy Redko
>
>
> JM> On Wed, Aug 11, 2021 at 10:05 AM Andriy Redko 
> wrote:
>
> >> Hey guys,
>
> >> I would like to initiate (or better to say, resume) the discussion
> >> regarding CXF 3.5.x and beyond.
> >> The 3.5.x has been  in the making for quite a while but has not seen any
> >> releases yet. As far as
> >> I know, we have only pending upgrade to Apache Karaf 4.3.3 (on SNAPSHOT
> >> now) so be ready to meet
> >> JDK 17 LTS next month. I think this is a good opportunity to release
> 3.5.0
> >> but certainly looking
> >> for ideas and opinions here. Importantly, I think for 3.5.x the JDK-8
> >> should be supported as the minimal
> >> required JDK version (just an opinion since JDK-8 is still very widely
> >> used).
>
> >> On the other side, many libraries (Jetty, wss4j, ...) are bumping the
> >> baseline to JDK-11. The work
> >> @Colm is doing to update to OpenSaml 4.x [1] is a good argument to have
> >> the JDK-11+ release line. Should
> >> we have a dedicated 3.6.x or 4.x.x branch(es) for that?
>
> >> Last but not least, Jakarta 9.0+ support. Last year we briefly talked
> >> about it [2], at this moment it
> >> looks like having dedicated release line (4.x/5.x) with Jakarta
> artifacts
> >> is beneficial in long term.
> >> Large chunk [3] of work has been already done in this direction. The
> >> Spring 6 milestones with Jakarta
> >> support are expected to land in Q4/2021 [4] but I am not sure what plans
> >> Apache Karaf team has, @Freeman
> >> do you have any insights?
>
>
> JM> For Jakarta EE9 support , the another option could be adding a new
> maven
> JM> module to transform cxf artifacts
> JM> with jakarta package name. This transformed artifact can coexist with
> the
> JM> javax namespace with "jakarta" classifier,
> JM> and we don't have to maintain two branches until Jakarta EE10 and
> there are
> JM> new features added.
>
> JM> Other projects like hibernate and jackson use this shade plugin or
> Eclipse
> JM> transformer to support jakarta ee9:
>
> JM>
> https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core-jakarta/hibernate-core-jakarta.gradle#L100
>
> JM>
> https://github.com/FasterXML/jackson-jaxrs-providers/blob/2.12/json/pom.xml#L115
>
>
>
> >> To summarize briefly:
> >>  - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline
> >>  - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK
> >> version (Jetty 10, ...)
> >>  - branch off 5.x (4.x?) to continue the work on supporting Jakarta
> 

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko]

Hi Jim,

I will try to answer your questions, other guys will definitely share more 
thoughts, please see mine inlined.

>> What's the task for JDK-17 LTS preparation ?  Do we need to support build 
>> 3.5.0 with JDK-17 ?

Build + All tests are green.
Apache Karaf 4.3.3 will support JDK17 so our OSGi test suites will pass.
Besides that, there is still some work to do [1] but at least we have 
workarounds.

>> For Jakarta ee9 support branch 4.x with source code change to support 
>> jakarta namespace , we have to wait for spring and other 
>> third party dependencies jakarta ee9 ready.  Now we don't know when these 
>> dependencies are all ready and we can start this work.

This is correct, the earliest we could expect something is Q4/2021 (fe Spring). 
 
>> Given there is no features added in Jakarta ee 9.1 besides the namespace 
>> change, we can provide the jakarta calssfier maven artifacts 
>> and binary release in 3.6.x or 4.x with transformation or other better 
>> approach will be enough.We provide jakarta ee9 support early, 
>> then we can get more feedback on this topic.

It is definitely the option we have among others to discuss. I have no doubts 
that everyone has rough idea of the pros and cons
each option has, as the team we are trying to pick the best path forward. 
Jakarta EE 10 is coming in Q1/2022 [2], we should keep it 
in mind as well.

Thank you!

[1] https://issues.apache.org/jira/browse/CXF-8407
[2] 
https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10#jakarta-ee-10-release-plan


Best Regards,
Andriy Redko

JM> On Wed, Aug 11, 2021 at 8:26 PM Andriy Redko  wrote:

>> Hey Jim, Romain,

>> Thank you guys, I think Romain's suggestion to move 3.5.x to JDK-11
>> baseline is good idea, we would
>> still be maintaining 3.4.x for a while, covering JDK-8 based deployments.
>> Regarding Jakarta, yes, I
>> certainly remember the discussion regarding the build time approach,
>> personally with time I came to the
>> conclusion that this is not the best option for at least 2 reasons:
>>  - differences between source vs binary artifacts are very confusing
>> (source imports javax,
>>binary has jakarta, or vice versa), I think we all run into that from
>> time to time
>>  - Jakarta is the way to go, the mainstream should have first class support

>> Just my 5 cents, but we certainly should consider this approach as well,
>> there are good points to
>> follow it, summarizing what we have at the moment:

>> Option #1:
>>  - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline
>>  - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK
>> version (Jetty 10, ...)
>>  - branch off 5.x (4.x?) to continue the work on supporting Jakarta 9.0+,
>> with JDK-11 as the minimal
>>required JDK version (Jetty 11, ...)


JM> What's the task for JDK-17 LTS preparation ?  Do we need to support build
JM> 3.5.0 with JDK-17 ?

JM> For Jakarta ee9 support branch 4.x with source code change to support
JM> jakarta namespace , we have to wait for spring and other
JM> third party dependencies jakarta ee9 ready.  Now we don't know when these
JM> dependencies are all ready and we can start this work.

JM> Given there is no features added in Jakarta ee 9.1 besides the namespace
JM> change, we can provide the jakarta calssfier maven artifacts and binary
JM> release in 3.6.x or 4.x with transformation or other better approach will
JM> be enough.We provide jakarta ee9 support early, then we can get more
JM> feedback on this topic.




>> Option #2:
>>  - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline
>>  - handle javax by a build setup (with api validation at build time to
>> avoid regressions) and use jakarta package as main api in the project
>> (Romain), or
>>adding a new maven module to transform cxf artifacts with jakarta
>> package name (Jim)

>>  Option #3:
>>  - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline
>>  - move master to 4.x to continue the work on supporting Jakarta 9.0+,
>> with JDK-11 as the minimal
>>required JDK version (Jetty 11, ...)

>> Thank you!

>> Best Regards,
>> Andriy Redko


>> JM> On Wed, Aug 11, 2021 at 10:05 AM Andriy Redko 
>> wrote:

>> >> Hey guys,

>> >> I would like to initiate (or better to say, resume) the discussion
>> >> regarding CXF 3.5.x and beyond.
>> >> The 3.5.x has been  in the making for quite a while but has not seen any
>> >> releases yet. As far as
>> >> I know, we have only pending upgrade to Apache Karaf 4.3.3 (on SNAPSHOT
>> >> now) so be ready to meet
>> >> JDK 17 LTS next month. I think this is a good opportunity to release
>> 3.5.0
>> >> but certainly looking
>> >> for ideas and opinions here. Importantly, I think for 3.5.x the JDK-8
>> >> should be supported as the minimal
>> >> required JDK version (just an opinion since JDK-8 is still very widely
>> >> used).

>> >> On the other side, many libraries (Jetty, wss4j, ...) are bumping the
>> >> baseline to JD

Re: External WSDLS and connection/read timeouts

[Andriy Redko]

Hi Manuel,

AFAIK CXF does not use 
org.springframework.core.io.AbstractFileResolvingResource (at least, directly).
Could you please trace where the last resource fetching attempt is coming from?
Thank you.

Best Regards,
Andriy Redko

SM> Hi everyone,

SM> we are using Camel CXF and found the following problem:
SM> It can happen that a route is trying to start for an infinite amount of 
time due to missing response from WSDL endpoint.

SM> Setup:
SM> A CXF endpoint that is using an external WSDL (i.e. 
wsdlURL=http://someHost/test/wsdl)
SM> The WSDL endpoint is not responding
SM> A conduit configured with 100ms timeouts (connections- and read-timeout)

SM> Test:
SM> I attached a sample app to this mail. To start the application, start 
DemoApplication.java. It will start a camel route containing a CXF endpoint. 
The CXF endpoint in the route tries to read an external WSDL. The endpoint for 
this WSDL is doing a 15 minute sleep before responding to simulate a "no 
response from WSDL endpoint" (implemented in RouteController). The conduit is 
configured with 100ms timeouts for connection- and readtimeout

SM> The application will fail to start if the route cannot be started. Since 
the WSDL can't be fetched within the 100ms timeout, I would expect the 
app-startup to fail at least within 1 minute. However the startup seems to go 
on for an infinite amount of time.


SM> I did some debugging and found several requests are done for the WSDL with 
different timeouts (in this order):


SM>   1.  org.apache.cxf.transport.http.URLConnectionHTTPConduit:134

SM>   *   connectionTimeout 100 ms
SM>   *   readTimeout 100 ms
SM>   *   timeout-values are taken from conduit


SM>   1.  org.apache.cxf.resource.URIResolver:282

SM>   *   connectionTimeout 30 seconds
SM>   *   readTimeout 60 seconds
SM>   *   hardcoded values


SM>   1.  org.springframework.core.io.AbstractFileResolvingResource:60

SM>   *   connectionTimeout 0 //infinite waiting
SM>   *   readTimeout 0  //infinite waiting
SM>   *   no explicit timeouts are set

SM> Our main problem here is the last request that has no timeout configured at 
all. I attached the stacktrace of the blocked thread.

SM> I would expect that the timeouts from the conduit are applied. This seems 
not to be the case so I think this is a bug. What do you think?

SM> Thanks in advance
SM> Best regards,
SM> Manuel

Re: [DISCUSS] CXF 3.5.x and beyond

[Romain Manni-Bucau]

I'm not sure I see why you need spring to start this work. The expected is
there already so spring module can still rely on javax, be made jakarta
friendly using shade plugin or alike and that's it until a spring native
integration is there.
Worse case cxf-spring will not be usable with jakarta - which still enabled
all other usages, best case if spring makes the transition smooth is that
it will work smoothly without more investment than for the rest of the
build.
The pro of that options is that it will reduce the number of unofficial cxf
relocations sooner IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 16 août 2021 à 23:40, Andriy Redko  a écrit :

> Hi Jim,
>
> I will try to answer your questions, other guys will definitely share more
> thoughts, please see mine inlined.
>
> >> What's the task for JDK-17 LTS preparation ?  Do we need to support
> build 3.5.0 with JDK-17 ?
>
> Build + All tests are green.
> Apache Karaf 4.3.3 will support JDK17 so our OSGi test suites will pass.
> Besides that, there is still some work to do [1] but at least we have
> workarounds.
>
> >> For Jakarta ee9 support branch 4.x with source code change to support
> jakarta namespace , we have to wait for spring and other
> >> third party dependencies jakarta ee9 ready.  Now we don't know when
> these dependencies are all ready and we can start this work.
>
> This is correct, the earliest we could expect something is Q4/2021 (fe
> Spring).
>
> >> Given there is no features added in Jakarta ee 9.1 besides the
> namespace change, we can provide the jakarta calssfier maven artifacts
> >> and binary release in 3.6.x or 4.x with transformation or other better
> approach will be enough.We provide jakarta ee9 support early,
> >> then we can get more feedback on this topic.
>
> It is definitely the option we have among others to discuss. I have no
> doubts that everyone has rough idea of the pros and cons
> each option has, as the team we are trying to pick the best path forward.
> Jakarta EE 10 is coming in Q1/2022 [2], we should keep it
> in mind as well.
>
> Thank you!
>
> [1] https://issues.apache.org/jira/browse/CXF-8407
> [2]
> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10#jakarta-ee-10-release-plan
>
>
> Best Regards,
> Andriy Redko
>
> JM> On Wed, Aug 11, 2021 at 8:26 PM Andriy Redko  wrote:
>
> >> Hey Jim, Romain,
>
> >> Thank you guys, I think Romain's suggestion to move 3.5.x to JDK-11
> >> baseline is good idea, we would
> >> still be maintaining 3.4.x for a while, covering JDK-8 based
> deployments.
> >> Regarding Jakarta, yes, I
> >> certainly remember the discussion regarding the build time approach,
> >> personally with time I came to the
> >> conclusion that this is not the best option for at least 2 reasons:
> >>  - differences between source vs binary artifacts are very confusing
> >> (source imports javax,
> >>binary has jakarta, or vice versa), I think we all run into that from
> >> time to time
> >>  - Jakarta is the way to go, the mainstream should have first class
> support
>
> >> Just my 5 cents, but we certainly should consider this approach as well,
> >> there are good points to
> >> follow it, summarizing what we have at the moment:
>
> >> Option #1:
> >>  - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline
> >>  - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK
> >> version (Jetty 10, ...)
> >>  - branch off 5.x (4.x?) to continue the work on supporting Jakarta
> 9.0+,
> >> with JDK-11 as the minimal
> >>required JDK version (Jetty 11, ...)
>
>
> JM> What's the task for JDK-17 LTS preparation ?  Do we need to support
> build
> JM> 3.5.0 with JDK-17 ?
>
> JM> For Jakarta ee9 support branch 4.x with source code change to support
> JM> jakarta namespace , we have to wait for spring and other
> JM> third party dependencies jakarta ee9 ready.  Now we don't know when
> these
> JM> dependencies are all ready and we can start this work.
>
> JM> Given there is no features added in Jakarta ee 9.1 besides the
> namespace
> JM> change, we can provide the jakarta calssfier maven artifacts and binary
> JM> release in 3.6.x or 4.x with transformation or other better approach
> will
> JM> be enough.We provide jakarta ee9 support early, then we can get more
> JM> feedback on this topic.
>
>
>
>
> >> Option #2:
> >>  - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline
> >>  - handle javax by a build setup (with api validation at build time to
> >> avoid regressions) and use jakarta package as main api in the project
> >> (Romain), or
> >>adding a new maven module to transform cxf artifacts with jakarta
> >> package name (Jim)