lighty-modules/lighty-restconf-netty-nb-community/src/main/java/io/lighty/modules/northbound/netty/restconf/community/impl/config/NettyRestConfConfiguration.java (133-136)

The setRestconfServletContextPath method, which contained logic to remove a leading slash from the path, has been removed. This logic is not present in the getter or any other part of the class. If a configuration file provides a path with a leading slash (like the new restconf-config.json test file does), it will be used as-is, which might cause issues with servlet path mapping if the downstream code expects a path without a leading slash.

Was the removal of this logic intentional? If the path should not have a leading slash, consider moving this logic to the getter to ensure consistency.

For example:

public String getRestconfServletContextPath() {
    return restconfServletContextPath.startsWith("/")
        ? restconfServletContextPath.substring(1) : restconfServletContextPath;
}

This would make the class's behavior more robust. The field restconfServletContextPath is initialized to "restconf" which has no leading slash, but can be overridden by JSON deserialization.

lighty-modules/lighty-restconf-netty-nb-community/src/test/java/io/lighty/modules/northbound/netty/restconf/community/impl/tests/NettyRestConfConfigurationTest.java (41)

This test loads configuration from restconf-config.json but doesn't verify the restconfServletContextPath property. Given the changes to how this property is handled in NettyRestConfConfiguration, it would be valuable to add an assertion here to ensure it's parsed as expected and to document the expected behavior (i.e., whether the leading slash is preserved).

For example, you could add:
Assert.assertEquals(restConfConfiguration.getRestconfServletContextPath(), "/restconf-path");

lighty-modules/lighty-restconf-netty-nb-community/src/test/java/io/lighty/modules/northbound/netty/restconf/community/impl/tests/NettyRestConfTestBase.java (56)

The call to started.get() blocks until the future completes or the @BeforeClass timeout is reached. This can make tests hang and harder to debug. It's also inconsistent with the nettyRestConf.start().get(10_000, TimeUnit.MILLISECONDS) call later. It's a good practice to use a timeout on all blocking get() calls to prevent tests from hanging.

        started.get(10, TimeUnit.SECONDS);

lighty-modules/lighty-restconf-netty-nb-community/src/test/java/io/lighty/modules/northbound/netty/restconf/community/impl/tests/NettyRestConfTestBase.java (104-114)

The switch statement uses magic numbers (-1, 1, 2, etc.) to represent TestNG result statuses. This makes the code harder to read and maintain. It's better to use the named constants provided by the ITestResult interface (e.g., ITestResult.SUCCESS, ITestResult.FAILURE).

Note: This change will require adding import org.testng.ITestResult;.

    private static String parseTestNGStatus(final int testResultStatus) {
        return switch (testResultStatus) {
            case ITestResult.CREATED -> "CREATED";
            case ITestResult.SUCCESS -> "SUCCESS";
            case ITestResult.FAILURE -> "FAILURE";
            case ITestResult.SKIP -> "SKIP";
            case ITestResult.SUCCESS_PERCENTAGE_FAILURE -> "SUCCESS_PERCENTAGE_FAILURE";
            case ITestResult.STARTED -> "STARTED";
            default -> "N/A";
        };
    }