[jira] [Comment Edited] (KAFKA-14470) Move log layer to storage module

["Satish Duggana (Jira)" <ji...@apache.org>]

    [ 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)