[RELEASE REQUEST] Next 3.x release?

[Romain Manni-Bucau]

Hi all,

Is it possible to get a 3.5.4 or 3.6 out to be able to get back
https://issues.apache.org/jira/browse/CXF-8732 please ?

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

[GitHub] [cxf] reta merged pull request #991: use getter in case of overwritten from child class

[GitBox]

reta merged PR #991:
URL: https://github.com/apache/cxf/pull/991


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

JDK 19 first Release Candidates!

[David Delabassee]

Greetings!

I hope you had a chance to take some time off. On our side, and despite 
the summer vacation, everything is on track for the Java 19 GA release 
on September 20th with JDK 19 now in the Release Candidate Phase [1]. If 
you haven't done so yet, it is time to start testing your project(s) 
using the JDK 20 Early-Access builds. Speaking of Early-Access builds, 
there is now a new set of EA builds, i.e., the jextract EA builds. 
jextract is a tool developed under the Project Panama umbrella whose 
goal is to mechanically generates Java bindings from native library 
headers. If you are using the Foreign Function & Memory API (Preview 
Feature in JDK 19), make sure to check jextract too (see the jextract 
section below).


[1] https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006861.html


## Heads-up - New system properties for `System.out` and `System.err` in 
JDK 19


Two new system properties, `stdout.encoding` and `stderr.encoding`, have 
been introduced. The value of these system properties is the encoding 
used by the standard output (`System.out`) and standard error 
(`System.err`) streams. The default values of these system properties 
depend on the platform. The values take on the value of the 
`native.encoding` property when the platform does not provide streams 
for the console. The properties can be overridden on the launcher's 
command line option, with `-D`, to set them to UTF-8 where required. For 
more details see https://bugs.openjdk.org/browse/JDK-8283620



## Heads-up - SSLSocketImpl finalizer implementation removed in JDK 19

The finalizer implementation in SSLSocket has been removed, with the 
underlying native resource releases now done by the Socket 
implementation. With this update, the TLS close_notify messages will no 
longer be emitted if SSLSocket is not explicitly closed. Not closing 
Sockets properly is an error condition that should be avoided. 
Applications should always close sockets and not rely on garbage 
collection. For more details see https://bugs.openjdk.org/browse/JDK-8212136



## Heads-up - New providerPath jarsigner option in JDK 19

A new `-providerPath` option has been added to the jarsigner. This 
option is used to specify the class path of an alternate keystore 
implementation, it can be used together with the -providerClass option. 
For more details see https://bugs.openjdk.org/browse/JDK-8281175



## JDK 19 Release Candidate builds

JDK 19 first Release Candidates (builds 36) are now available [2], and 
are provided under the GNU General Public License v2, with the Classpath 
Exception. The Release Notes are available here [3].


[2] https://jdk.java.net/19/
[3] https://jdk.java.net/19/release-notes


## JDK 20 Early-Access builds

JDK 20 Early-Access builds 11 are now available [4], and are provided 
under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are available here [5].


[4] https://jdk.java.net/20/
[5] https://jdk.java.net/20/release-notes

### Recent changes that maybe of interest:

- JDK-8282730: LdapLoginModule throw NPE from logout method after login 
failure

- JDK-8290706: Remove the support for inline contiguous allocations
- JDK-8289551: Conversions between bit representations of half precision 
values and floats
- JDK-8290485: [vector] REVERSE_BYTES for byte type should not emit any 
instructions
- JDK-8289137: Automatically adapt Young/OldPLABSize and when setting 
only MinTLABSize

- JDK-8290034: Auto vectorize reverse bit operations.
- JDK-8290868: NMT: MallocSiteTable statistics improvements
- JDK-8291822: ARM32: Build errors with GCC 11 in 
frame::saved_oop_result [Reported by JaCoCo]

- JDK-8289249: Add methods to Elements for record constructors
- JDK-8283232: x86: Improve vector broadcast operations
- JDK-8288327: Executable.hasRealParameterData should not be volatile
- JDK-8291360: Create entry points to expose low-level class file 
information

- JDK-8290840: Refactor the "os" class
- JDK-8292327: InflaterInputStream.read throws EOFException
- JDK-8155246: Throw error if default java.security file is missing
- JDK-8289332: Auto-generate ids for user-defined headings
- JDK-8292153: x86: Represent Registers as values


## Jextract Early-Access Builds

Early Access Builds 19-jextract+2-3 (2022/7/19) are now available [6]. 
These open-source builds are provided under the GNU General Public 
License, version 2, with the Classpath Exception.


These builds are from the OpenJDK jextract project [7] which is part of 
Code Tools [8]. jextract is a tool developed under the Panama umbrealla 
whose goal is to mechanically generate Java bindings from native library 
headers. These EA builds are intended for advanced users, and are 
provided as a convenience so that they don't need to build it from the 
sources. Additional notes on builds, documentation and known issues are 
available at [6].


Please subscribe to the jextract mailing list [9] to share feedback.

[6] https://jdk.java.net/jext

[GitHub] [cxf] awrb commented on pull request #992: Cxf 8710

[GitBox]

awrb commented on PR #992:
URL: https://github.com/apache/cxf/pull/992#issuecomment-1222759090

   Hi @reta, I updated the pull request after the code review.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [cxf] reta commented on a diff in pull request #990: specs says type in header should at+jwt

[GitBox]

reta commented on code in PR #990:
URL: https://github.com/apache/cxf/pull/990#discussion_r951956470


##
rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/AbstractOAuthDataProvider.java:
##
@@ -646,7 +647,12 @@ protected String processJwtAccessToken(JwtClaims 
jwtCliams) {
 // It will JWS-sign (default) and/or JWE-encrypt
 OAuthJoseJwtProducer processor =
 getJwtAccessTokenProducer() == null ? new OAuthJoseJwtProducer() : 
getJwtAccessTokenProducer();
-return processor.processJwt(new JwtToken(jwtCliams));
+
+JwsHeaders jwsHeaders = new JwsHeaders();

Review Comment:
   @arthurchan35 it does not seem to be the solving the problem at large:
- as you may see in the comment [1], it could be JWS or JWE
- for `JWE`, the `JwsHeaders` are not used, the `JweHeaders` are 
   
   Looking into the right place to apply the spec recommendation, but on more 
general note, we need to introduce  a member to `JoseType` for `at+JWT` and 
respective constant to `JoseConstants`.
   
   [1] 
https://github.com/apache/cxf/pull/990/files#diff-1c24cdb27ac335b1f77f921093e723cfeeda77ce8e14d3196d2d1977a3d1effaR648



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [cxf] reta commented on a diff in pull request #990: specs says type in header should at+jwt

[GitBox]

reta commented on code in PR #990:
URL: https://github.com/apache/cxf/pull/990#discussion_r951956470


##
rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/AbstractOAuthDataProvider.java:
##
@@ -646,7 +647,12 @@ protected String processJwtAccessToken(JwtClaims 
jwtCliams) {
 // It will JWS-sign (default) and/or JWE-encrypt
 OAuthJoseJwtProducer processor =
 getJwtAccessTokenProducer() == null ? new OAuthJoseJwtProducer() : 
getJwtAccessTokenProducer();
-return processor.processJwt(new JwtToken(jwtCliams));
+
+JwsHeaders jwsHeaders = new JwsHeaders();

Review Comment:
   @arthurchan35 it does not seem to be solving the problem at large:
- as you may see in the comment [1], it could be JWS or JWE
- for `JWE`, the `JwsHeaders` are not used, the `JweHeaders` are 
   
   Looking into the right place to apply the spec recommendation, but on more 
general note, we need to introduce  a member to `JoseType` for `at+JWT` and 
respective constant to `JoseConstants`.
   
   [1] 
https://github.com/apache/cxf/pull/990/files#diff-1c24cdb27ac335b1f77f921093e723cfeeda77ce8e14d3196d2d1977a3d1effaR648



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko]

Hey Jim,

I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real blockers. 
For Swagger 1.x, we could
go ahead and drop the support altogether, this is quite isolated feature. OSGi 
and Karaf are not, those
penetrated very deep into core. What worries me, if we drop everything 
OSGi/Karaf related from 4.0.0, we
may need to bring it back some time in the future (with OSGi R9 [4] fe) and 
that is going to be quite 
difficult. From other side, this is probably the only option to have 4.0.0 
milestone out (we excluded some
modules from the build right now but that is more like a temporary hack which 
we should not release upon,
even alphas). What do you think guys?

Best Regards,
Andriy Redko

[1] https://issues.apache.org/jira/browse/CXF-8714
[2] https://issues.apache.org/jira/browse/CXF-8723
[3] https://issues.apache.org/jira/browse/CXF-8722
[4] https://github.com/osgi/osgi/milestone/5

JM> After we merged the jakarta branch to default branch main branch,  do we
JM> need to create some
JM> plan to do a future 4.x release?

JM> There are a couple of to-do things under
JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla,
JM> and for some of them we can't do more things because of the jakarta
JM> dependency missing. It seems that some of the dependencies won't
JM> have the jakarta namespace artifact released in the near future.  Should we
JM> have some milestone/alpha release
JM> before all these dependencies are available ?  And if we want to do a
JM> milestone release, what do you think we should have in
JM> this 4.0.0-M1 release ?


JM> Thanks,
JM> Jim



JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma  wrote:

>> Thanks Andriy too for driving this and moving forward !
>>
>> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko  wrote:
>>
>>> Hey guys,
>>>
>>> The Jakarta branch [1] just went into master, HUGE THANKS everyone for
>>> tremendous effort! Please
>>> note, it is still work in progress, the things to be done are tracked
>>> under [2], feel free to
>>> add more items or pick the existing ones. The master builds still have
>>> some tests failing, but those
>>> should be fixed shortly. With that, 3.6.x-fixes becomes the "mirror" of
>>> the master but for javax.*
>>> packages. Cherrypicking / backporting changes from master might be a bit
>>> more complicated (jakarta.* -> javax.*)
>>> but manageable.
>>>
>>> One more thing, the pull requests against master and 3.6.x / 3.5.x are
>>> build using JDK-17 now (was JDK-11
>>> before), this is due to the fact that master needs JDK-17, as it's Spring
>>> 6 / Spring Boot 3 JDK baseline.
>>> I have difficulties configuring Jenkins Maven builds + Github Pull
>>> Request builder per branch. It may be
>>> possible with pipeline, I will experiment with that. Please share any
>>> concerns, comments or feedback, it
>>> is highly appreciated.
>>>
>>> Thank you!
>>>
>>> [1] https://github.com/apache/cxf/pull/912
>>> [2] https://issues.apache.org/jira/browse/CXF-8371
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>> COh> +1 from me.
>>>
>>> COh> Colm.
>>>
>>> COh> On Thu, May 26, 2022 at 2:40 AM Jim Ma  wrote:
>>> >>
>>> >> Hi Andriy,
>>> >> A good plan. I agree with all these changes and support versions.
>>> >>
>>> >> Thanks,
>>> >> Jim
>>> >>
>>> >> On Mon, May 23, 2022 at 12:45 AM Andriy Redko 
>>> wrote:
>>> >>
>>> >> > Hey folks,
>>> >> >
>>> >> > While the work on 4.x / Jakarta is slowly but steadily moving
>>> forward, it
>>> >> > is
>>> >> > time to think about next 3.x release line. As we discussed in this
>>> thread,
>>> >> > it
>>> >> > seems we agreed on 3.6.x to be next javax.* based release, with
>>> JDK-11 as
>>> >> > the
>>> >> > baseline. We have new Spring Boot 2.7.0 just released [1], along
>>> with tons
>>> >> > of other
>>> >> > related projects. I would like to propose to:
>>> >> >  - branch off 3.6.x-fixes (from master) and work on upgrades (+ some
>>> new
>>> >> > features)
>>> >> >  - as per @Jim suggestion, merge (very soon) Jakarta branch [2] into
>>> master
>>> >> >
>>> >> > From the support perspective, it means we would need to maintain
>>> 3.4.x for
>>> >> > some
>>> >> > time, plus 3.5.x, 3.6.x and 4.0.0 (when released at some point).
>>> What do
>>> >> > you
>>> >> > think guys? Thank you!
>>> >> >
>>> >> > [1]
>>> https://spring.io/blog/2022/05/19/spring-boot-2-7-0-available-now
>>> >> > [2] https://github.com/apache/cxf/pull/912
>>> >> >
>>> >> > Best Regards,
>>> >> > Andriy Redko
>>> >> >
>>> >> >
>>> >> > JM> Hi Andriy,
>>> >> > JM> I took some time to look at the CXF java11 support and spring
>>> >> > decoupling
>>> >> > JM> last week.
>>> >> > JM> Here are some thoughts and initial work:
>>> >> > JM> 1) Use cross compile to support java11 . We can simply change
>>> >> > JM>  in pom.xml to 11.
>>> >> > JM> This will allow the maven compiler plugin to build cxf with
>>> java11.
>>> >> > JM> 2) We can look at creating some separate modules for Spring
>>> relevant
>>> >> > JM> code/configuration in the future

[GitHub] [cxf] reta commented on pull request #992: Cxf 8710

[GitBox]

reta commented on PR #992:
URL: https://github.com/apache/cxf/pull/992#issuecomment-1223279038

   Thanks a lot, @awrb !


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma]

For OSGI and Karaf Jakarta native, I remembered I talked with Freeman about
this topic several months ago and got to know
there won't be Jakarta namespace support work in the future. I don't know
if this has changed.
Freeman, do you have some update on this ?


On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko  wrote:

> Hey Jim,
>
> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real
> blockers. For Swagger 1.x, we could
> go ahead and drop the support altogether, this is quite isolated feature.
> OSGi and Karaf are not, those
> penetrated very deep into core. What worries me, if we drop everything
> OSGi/Karaf related from 4.0.0, we
> may need to bring it back some time in the future (with OSGi R9 [4] fe)
> and that is going to be quite
> difficult. From other side, this is probably the only option to have 4.0.0
> milestone out (we excluded some
> modules from the build right now but that is more like a temporary hack
> which we should not release upon,
> even alphas). What do you think guys?
>
> Best Regards,
> Andriy Redko
>
> [1] https://issues.apache.org/jira/browse/CXF-8714
> [2] https://issues.apache.org/jira/browse/CXF-8723
> [3] https://issues.apache.org/jira/browse/CXF-8722
> [4] https://github.com/osgi/osgi/milestone/5
>
> JM> After we merged the jakarta branch to default branch main branch,  do
> we
> JM> need to create some
> JM> plan to do a future 4.x release?
>
> JM> There are a couple of to-do things under
> JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla,
> JM> and for some of them we can't do more things because of the jakarta
> JM> dependency missing. It seems that some of the dependencies won't
> JM> have the jakarta namespace artifact released in the near future.
> Should we
> JM> have some milestone/alpha release
> JM> before all these dependencies are available ?  And if we want to do a
> JM> milestone release, what do you think we should have in
> JM> this 4.0.0-M1 release ?
>
>
> JM> Thanks,
> JM> Jim
>
>
>
> JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma  wrote:
>
> >> Thanks Andriy too for driving this and moving forward !
> >>
> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko  wrote:
> >>
> >>> Hey guys,
> >>>
> >>> The Jakarta branch [1] just went into master, HUGE THANKS everyone for
> >>> tremendous effort! Please
> >>> note, it is still work in progress, the things to be done are tracked
> >>> under [2], feel free to
> >>> add more items or pick the existing ones. The master builds still have
> >>> some tests failing, but those
> >>> should be fixed shortly. With that, 3.6.x-fixes becomes the "mirror" of
> >>> the master but for javax.*
> >>> packages. Cherrypicking / backporting changes from master might be a
> bit
> >>> more complicated (jakarta.* -> javax.*)
> >>> but manageable.
> >>>
> >>> One more thing, the pull requests against master and 3.6.x / 3.5.x are
> >>> build using JDK-17 now (was JDK-11
> >>> before), this is due to the fact that master needs JDK-17, as it's
> Spring
> >>> 6 / Spring Boot 3 JDK baseline.
> >>> I have difficulties configuring Jenkins Maven builds + Github Pull
> >>> Request builder per branch. It may be
> >>> possible with pipeline, I will experiment with that. Please share any
> >>> concerns, comments or feedback, it
> >>> is highly appreciated.
> >>>
> >>> Thank you!
> >>>
> >>> [1] https://github.com/apache/cxf/pull/912
> >>> [2] https://issues.apache.org/jira/browse/CXF-8371
> >>>
> >>> Best Regards,
> >>> Andriy Redko
> >>>
> >>> COh> +1 from me.
> >>>
> >>> COh> Colm.
> >>>
> >>> COh> On Thu, May 26, 2022 at 2:40 AM Jim Ma 
> wrote:
> >>> >>
> >>> >> Hi Andriy,
> >>> >> A good plan. I agree with all these changes and support versions.
> >>> >>
> >>> >> Thanks,
> >>> >> Jim
> >>> >>
> >>> >> On Mon, May 23, 2022 at 12:45 AM Andriy Redko 
> >>> wrote:
> >>> >>
> >>> >> > Hey folks,
> >>> >> >
> >>> >> > While the work on 4.x / Jakarta is slowly but steadily moving
> >>> forward, it
> >>> >> > is
> >>> >> > time to think about next 3.x release line. As we discussed in this
> >>> thread,
> >>> >> > it
> >>> >> > seems we agreed on 3.6.x to be next javax.* based release, with
> >>> JDK-11 as
> >>> >> > the
> >>> >> > baseline. We have new Spring Boot 2.7.0 just released [1], along
> >>> with tons
> >>> >> > of other
> >>> >> > related projects. I would like to propose to:
> >>> >> >  - branch off 3.6.x-fixes (from master) and work on upgrades (+
> some
> >>> new
> >>> >> > features)
> >>> >> >  - as per @Jim suggestion, merge (very soon) Jakarta branch [2]
> into
> >>> master
> >>> >> >
> >>> >> > From the support perspective, it means we would need to maintain
> >>> 3.4.x for
> >>> >> > some
> >>> >> > time, plus 3.5.x, 3.6.x and 4.0.0 (when released at some point).
> >>> What do
> >>> >> > you
> >>> >> > think guys? Thank you!
> >>> >> >
> >>> >> > [1]
> >>> https://spring.io/blog/2022/05/19/spring-boot-2-7-0-available-now
> >>> >> > [2] https://github.com/apache/cxf/pull/912
> >>> >> >
> >>> >> > Best Rega

Re: [RELEASE REQUEST] Next 3.x release?

[Andriy Redko]

Hi Romain,

I think it is feasible to have a release in a few weeks (if there are
no objections from the guys), from my side I have to wrap up one MTOM 
regression and one more issue related to MTOM content injection. 
Thanks.

Best Regards,
Andriy Redko


RMB> Hi all,

RMB> Is it possible to get a 3.5.4 or 3.6 out to be able to get back
RMB> https://issues.apache.org/jira/browse/CXF-8732 please ?

RMB> Thanks,
RMB> Romain Manni-Bucau
RMB> @rmannibucau  |  Blog
RMB>  | Old Blog
RMB>  | Github 
 |
RMB> LinkedIn  | Book
RMB>