[
https://issues.apache.org/jira/browse/KAFKA-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649225#comment-17649225
]
Satish Duggana edited comment on KAFKA-14470 at 12/19/22 10:13 AM:
-------------------------------------------------------------------
[~ijuma] I understand that the Java code uses slf4j classes and LogContext.
When we move scala related code with `Logging` dependency, we can change that
to use slf4j with LogContext. For example any abstract class that extends
Logging is moved to storage in Java then the implemented scala classes will
still expect the methods and use Logging instance from the abstract class which
is moved to Java. One possible example can be ShutdownableThread which extends
Logging. But there are several scala classes that extend ShutdownableThread and
use Logging methods.
There can be several ways to address it, a couple of them can be:
1. Port kafka.utils.Logging class to Java including all the methods and use it
in abstract class without any chages in implemented Scala classes.
2. Declare slf4j logger classes with LogContext in the abstract class. But the
scala classes that extends the ported Java abstract class can still use
kafka.utils.Logging by making the respective logger instantiation changes in
those scala classes.
was (Author: satish.duggana):
[~ijuma] I understand that the Java code uses slf4j classes and LogContext.
When we move scala related code with `Logging` dependency, we can change that
to use slf4j with LogContext. For example any abstract class that extends
Logging is moved to storage in Java then the implemented scala classes will
still expect the methods and use Logging instance from the abstract class which
is moved to Java. One possible example can be ShutdownableThread which extends
Logging. But there are several scala classes that extend ShutdownableThread.
There can be several ways to address it, a couple of them can be:
1. Port kafka.utils.Logging class to Java including all the methods and use it
in abstract class without any chages in implemented Scala classes.
2. Declare slf4j logger classes with LogContext in the abstract class. But the
scala classes that extends the ported Java abstract class can still use
kafka.utils.Logging by making the respective logger instantiation changes in
those scala classes.
> Move log layer to storage module
> --------------------------------
>
> Key: KAFKA-14470
> URL: https://issues.apache.org/jira/browse/KAFKA-14470
> Project: Kafka
> Issue Type: Improvement
> Reporter: Ismael Juma
> Assignee: Ismael Juma
> Priority: Major
>
> We introduced the `storage` module as part of KIP-405, but the existing log
> layer remains in the `core` module. Moving the log layer to the `storage`
> module would be another step towards improved modularity and build times
> (similar to `metadata`, `raft` and `group-coordinator`).
> We should do this in an incremental manner to make the code review process
> easier. I will create separate tasks, each one mapping to one pull request.
> In order to understand the feasibility, I tackled a few of the tasks myself.
> Help from the community is appreciated for the unassigned tasks, but it
> probably makes sense to do that after the initial PRs have been submitted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
