-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[trans to #10563][fix #9640] remove pulsar-client-admin-api dependency : pulsar-client-original
#10513
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
2dd33ad to
2ef02f5
Compare
pulsar-client-admin-api dependency : pulsar-client-original
|
/pulsarbot run-failure-checks |
f4601e6 to
13b8f5c
Compare
|
/pulsarbot run-failure-checks |
bf799e3 to
8f45944
Compare
|
@sijie @merlimat @jerrypeng @codelipenghui please help to review this PR if you have time, thanks. |
|
|
||
| <dependency> | ||
| <groupId>${project.groupId}</groupId> | ||
| <artifactId>pulsar-client-original</artifactId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need pulsar client explicitly for Kafka connector?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@merlimat I believe this is related to the conversion between pulsar's schema and kafka's schema. So kafka connector need pulsar-client-original which all schema impls are in the package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, @freeznet is right. we need Schema Impl classes
| @Override | ||
| public void completed(OffloadProcessStatus offloadProcessStatus) { | ||
| public void completed(String jsonString) { | ||
| Gson gson = new GsonBuilder().registerTypeAdapter(MessageId.class, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use Jackson for all the JSON ser/de, unless there's a particular reason not to do so. Please use ObjectMapperFactory.getThreadLocal()....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your suggestion. The reason why I use Gson here is that I noticed TopicsImpl.java is using Gson to de REST response to JsonObject already, like getInternalInfoAsync, so I havent try Jackson here to avoid additional imports.
And in this case, we want de MessageId.class to MessageIdImpl.class, Gson have a simpler way to map interface (MessageId.class) with implementation class (MessageIdImpl.class), for Jackson we cannot use @JsonDeserialize annotation because we dont want to have Jackson dependency in pulsar-client-admin-api, but I have googled with a solution with SimpleAbstractTypeResolver, like
ObjectMapper mapper = ObjectMapperFactory.create();
SimpleModule module = new SimpleModule("OffloadProcessStatusConvertModule",
Version.unknownVersion());
SimpleAbstractTypeResolver resolver = new SimpleAbstractTypeResolver();
resolver.addMapping(MessageId.class, MessageIdImpl.class);
module.setAbstractTypes(resolver);
mapper.registerModule(module);
So if we want to use Jackson here, we may try this way.
Also I do confuse with Gson and Jackson here in Pulsar, do we want to replace Gson with Jackson, or we will keep the mixed usage but prefer Jackson by default? And what are the concerns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
freeznet@fa05e38
here is a sample commit that changes Gson to Jackson.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to make sure to use Jackson, through the ObjectMapperFactory.getThreadLocal() since it comes configured with some settings.
If @JsonDeserialize annotations are the problem, there will be bigger problems porting the POJOs defined in pulsar-common.
The better option here is to untie the pulsar-client-admin-api from the POJOs. Instead, pulsar-client-admin-api should return Java interfaces instead of POJOs that are used for serialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@merlimat Indeed, there will be some problems with pulsar-common. But if we return Java interfaces instead of POJOs, we still need to have a mapping list to have Java Interface -> POJO so that Jackson can do the deserialization.
pulsar-client-admin-api/src/main/java/org/apache/pulsar/client/admin/PulsarAdmin.java
Show resolved
Hide resolved
eolivelli
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
pulsar-client-admin-api/src/main/java/org/apache/pulsar/client/admin/PulsarAdmin.java
Show resolved
Hide resolved
|
|
||
| <dependency> | ||
| <groupId>${project.groupId}</groupId> | ||
| <artifactId>pulsar-client-original</artifactId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, @freeznet is right. we need Schema Impl classes
a1f878f to
e5fd1b3
Compare
| // because we do not want to have jackson dependency in pulsar-client-admin-api | ||
| // In this case we use SimpleAbstractTypeResolver to map interfaces to impls | ||
| SimpleAbstractTypeResolver resolver = new SimpleAbstractTypeResolver(); | ||
| resolver.addMapping(OffloadProcessStatus.class, OffloadProcessStatusImpl.class); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@merlimat I have added a SimpleAbstractTypeResolver here, and will manually map interfaces with impl classes.
e5fd1b3 to
747d7fd
Compare
|
This PR introduced a new dependency |
| <artifactId>pulsar-client-original</artifactId> | ||
| <version>${project.parent.version}</version> | ||
| <groupId>com.google.code.gson</groupId> | ||
| <artifactId>gson</artifactId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if gson is not already a dependency imported by pulsar-client-original in 2.7.x I would like to not add it.
Users of pulsar-client-original already have Jackson and usually who uses pulsar-client-admin-api uses pulsar-client, so I would lean toward using only Jackson.
what's your plan for removing gson in a follow up patch ? this next patch will become a blocker for the 2.8 release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding gson as the dependency is a temporary action, with removal of pulsar-client-original and pulsar-package-core, pulsar-client-admin-api will lose dependency of gson, but we still have a lot of classes import gson, such as
pulsar/pulsar-client-admin-api/src/main/java/org/apache/pulsar/client/admin/Topics.java
Line 21 in 581fd5b
| import com.google.gson.JsonObject; |
I do understand that the 2.8 release is in a hurry, but there are indeed many problems that need to be fixed one by one in order to achieve the ultimate goal. So the removal of gson will be in a separate PR soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My problem was about "adding" gson, if it was not already there, so to me this is not a problem.
thanks for your clarification
|
/pulsarbot run-failure-checks |
eolivelli
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
747d7fd to
3629c7a
Compare
…ule for interface resolver # Conflicts: # pulsar-client-admin-api/pom.xml
3629c7a to
4a7dc75
Compare
…y-pulsar-client-original
pulsar-client-admin-api dependency : pulsar-client-originalpulsar-client-admin-api dependency : pulsar-client-original
|
due to my mistaken ops on the branch, this PR has been closed, so please move to #10563, sorry for the inconvenience. |
Fixes #9640
Part 1
Motivation
Module
pulsar-client-admin-apihas been introduced in #9246, but it pulling in many dependencies. That is undesirable for an "API" module. As @sijie @merlimat and @jerrypeng suggests, this pr resolves the issue and makepulsar-client-admin-apihas minimal transient dependences.This PR removes
pulsar-client-originalfrom the dependency, and resolves the issues. Later there will be sepreate PRs to remove other dependencies likepulsar-commonandpulsar-package-core.I will close #9842 and keep update here.
Modifications
remove
pulsar-client-originalfrompulsar-client-admin-api.Verifying this change