pandaapo commented on code in PR #3867:
URL: https://github.com/apache/eventmesh/pull/3867#discussion_r1576133454
##########
eventmesh-storage-plugin/eventmesh-storage-kafka/src/main/java/org/apache/eventmesh/storage/kafka/producer/ProducerImpl.java:
##########
@@ -42,36 +41,20 @@
@Slf4j
@SuppressWarnings("deprecation")
-public class ProducerImpl {
+public class ProducerImpl extends AbstractProducer {
private final KafkaProducer<String, CloudEvent> producer;
- private final Properties properties = new Properties();
- private final AtomicBoolean isStarted = new AtomicBoolean(false);
public ProducerImpl(Properties props) {
+ super(props);
+ properties.clear();
Review Comment:
Actually, when we read the code of `ProducerImpl` and `KafkaProducerImpl` ,
it is quite evident that the latter is merely a delegate class, delegating all
the specific details to former for actual processing. Of course, you can use
the code from the corresponding classes in RocketMQ module to refute me.
However, I personally favor the positioning of these two classes in Kafka
module, as their responsibilities are more clearly defined.
Finally Community Over Code. I'm willing to wait for more members in
community to express their views on this point. If the approach used in
RocketMQ module is more accepted, I will revise.
--
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: issues-unsubscr...@eventmesh.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@eventmesh.apache.org
For additional commands, e-mail: issues-h...@eventmesh.apache.org
