Update jaxb and jax-rs libs

[onobc]

Search before asking

• I searched in the issues and found nothing similar.

Motivation

Is there any plan to update Jaxb and JaxRS libs (from javax.* to jakarta.*)?

When using the Pulsar admin client 2.11.0 in a modern application that is using the more recent versions of Jaxb and JaxRS, the recent versions are the ones used. This may lead to confusion. The only reason it is working in this case is because the elder jaxb-api is still carried along that has the old annotations.

Solution

BUMP jakarta.ws.rs:jakarta.ws.rs-api from 2.1.6 to 3.1.0
BUMP jakarta.xml.bind:jakarta.xml.bind-api from 2.3.3 4.0.0
Remove javax.xml.bind:jaxb-api:2.3.1

Update all code references from javax.* to jakarta.*

Alternatives

No response

Anything else?

No response

Are you willing to submit a PR?

• I'm willing to submit a PR!

[tisonkun]

IIRC @shoothzj started a discussion similar to what is proposed here at: https://lists.apache.org/thread/74cq2tyt3h62tgop61br9w3rgwqtlcvm

cc @nodece @eolivelli shall we make an explicit consensus (vote) on this upgrade, or just proceeding this issue?

[nodece]

I have two ideas:

1. Migrate to jakarta.* from javax.* in the admin@3.0.0
2. Could you try to use the pulsar-client-admin-shaded in your project?

[onobc]

Hi @nodece ,

1. Migrate to jakarta.* from javax.* in the admin@3.0.0

Agreed. This is what I was referring to in the Solution section.

BUMP jakarta.ws.rs:jakarta.ws.rs-api from 2.1.6 to 3.1.0
BUMP jakarta.xml.bind:jakarta.xml.bind-api from 2.3.3 4.0.0
Remove javax.xml.bind:jaxb-api:2.3.1

Update all code references from javax.* to jakarta.*

And 3.0.0 sounds like the proper vehicle for that significant change.

2. Could you try to use the pulsar-client-admin-shaded in your project?

I am using pulsar-client-all which has the same effect.

On a positive note, I believe 2.11 did increase these libs being shaded (from 2.10.x). The only one that is not shaded is the javax.xml.bind:jaxb-api:2.3.1.

I would be satisfied w/ making the upgrade (and move to jakarta.*) in 3.0.0 and I can live w/ the 2.11.0 containing javax for now. It mostly triggering "prohibited classpath compatibility" checks on some apps.

[nodece]

BTW, the admin still needs compatible with the JDK 8, so I guess the javax.xml.bind:jaxb-api:2.3.1 needs to be fixed into shaded.

[tisonkun]

Hi @onobc! From the mailing list thread @shoothzj raised an issue that Spring Boot 2.x are still using the package name "javax". I found that you opened this issue due to add Pulsar to Spring Boot 3.x in spring-projects/spring-boot#34763. What do you think of this compatibility issue?

[onobc]

Hi @tisonkun ,

If the libs are all shaded it should not matter what version is used by the admin client - they are effectively invisible.
IIRC, the only remaining unshaded lib in 2.11.0+ is javax.xml.bind:jaxb-api:2.3.1.

In general, shading the libs that the admin client is using to do its job is the only safe (and most flexible) answer IMO. Otherwise, if the admin client exposes a popular lib(s) then we will immediately be in this JEE/SpringBoot/Java version matrix madness where we would have tradeoffs such as "If you want to use Pulsar 3.x then you have to use Spring Boot 3.x" etc..

I do think a helpful requirement (exit criteria) for this ticket would be to make sure that whatever solution we land on, that Spring Boot 2.x users can use both Pulsar client 2.x and 3.x. An example could be as follows:

• SB 2.7.x simple app using Jersey (could bootstrap here).
• In a user defined Jersey component (controller or endpoint) use admin client to query topics/namespaces and create topics etc.. Do this w/ both admin client 2.x and 3.x.
• In a user defined non-Jersey component (ApplicationRunner, Service, Bean, anything else that is not Jersey specific) use admin client to query topics/namespaces and create topics etc.. Do this w/ both admin client 2.x and 3.x.

Thanks for pinging me and bringing this up.

[onobc]

I just noticed that the 3.0.0 milestone only has 2 issues associated w/ it. Can we get this issue in as well? Also, when will there be an RC for 3.0.0?

[tisonkun]

For 3.0.0, the schedule is set as:

• 2023-04-11 - RC-1
• 2023-04-18 - RC-2
• 2023-04-25 - RC-3
• 2023-05-02 - Announce 3.0 Release

You can subscribe to dev@pulsar.apache.org for updates. For example, RC-1 is out at https://lists.apache.org/thread/jf0zrb84j9sj7106jyd9gqlw1rcp6k4m

Can we get this issue in as well

Given the schedule above, I'm afraid that we're already code freeze. Anyway, we share a volunteer-based community so it still need a volunteer to find time and take it over.

[tisonkun]

Maybe I can cc the release manager @RobertIndie @poorbarcode @cbornet here for advice. This can impact how users integrate with 3.0.0 but I understand that we don't have too much time now following the time-based release cycle.

[onobc]

Thanks for the info @tisonkun ,

If it comes down to just finding a resource to implement I could probably volunteer for that as this is quite important to our usage of the client.

[nodece]

Hi @onobc, I made #20106 to fix this issue, could you confirm this PR?