Dubbo: unable to build dubbo-common ( unit test fail in AdaptiveClassCodeGeneratorTest )

[AlbumenJ]

• [x] I have searched the issues of this repository and believe that this is not a duplicate.
• [x] I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

• Dubbo version: 2.7.5
• Operating System version: Windows 10 1903
• Java version: 1.8.0_221

Steps to reproduce this issue

1. in root folder execute "mvn clean test"

Expected Result

pass unit test

Actual Result

org.opentest4j.AssertionFailedError: expected: but was:
at org.apache.dubbo.common.extension.AdaptiveClassCodeGeneratorTest.testGenerate(AdaptiveClassCodeGeneratorTest.java:45)

Any try

the souce of is AdaptiveClassCodeGeneratorTest

public class AdaptiveClassCodeGeneratorTest {

    @Test
    public void testGenerate() throws IOException {
        AdaptiveClassCodeGenerator generator = new AdaptiveClassCodeGenerator(HasAdaptiveExt.class, "adaptive");
        String value = generator.generate();
        URL url = getClass().getResource("/org/apache/dubbo/common/extension/adaptive/HasAdaptiveExt$Adaptive");
        try (InputStream inputStream = url.openStream()) {
            String content = IOUtils.read(new InputStreamReader(inputStream, "UTF-8"));
            assertTrue(content.contains(value));
        }
    }
}

When I add the following code to it, the unit pass.

            value = value.replace("\r","");
            value = value.replace("\n","");
            content = content.replace("\r","");
            content = content.replace("\n","");

[htynkn]

Currently we are using travis CI which base on linux, it maybe have some issue for windows platform.

[AlbumenJ]

Does Dubbo have plan to make unit-test adaptation on windows platform? (or maybe I can make a little contribute on it)

[xiantang]

i think unit-test can running in windows platform is very necessary. it can help developer who work on windows platform more easily to verify features.

[htynkn]

i think unit-test can running in windows platform is very necessary. it can help developer who work on windows platform more easily to verify features.

yeah. I agree. I have some ideas at this moment.

We are using travis ci, it has window platform support(Only Windows Server, version 1809 is currently supported), special os will lead more waiting time when running CI. we need a trade off.

For your question at this moment. @AlbumenJ I have some suggestions:

• Skip unit test when you build jar (add -DskipTests).
• if you have time, could you try to find a better way to make this unit test works. we are happy to accept any PR which can make things better. but I would like to know if there is other way instead of using replace. it may confuse people.
• or ignore all failed tests in windows platform, and only run it in linux platform. I think junit5 provide related feature.

Also, I'm not sure if this is only unit test issue in windows platform or there are some function issue in windows platform too. I don't have a PC which running Windows so I can't confirm this

[xiantang]

@htynkn junit5 have the feature which can only run test on linux with the @EnableOnOs annotations. but I think both adaptation windows and unix in this test case is better nad not hard.

[AlbumenJ]

In these days, I try to make unit-test running on Windows platform correctly and I found there are several problems:

• In Windows, files use '\r\n' to seperate lines ( which this issue mentioned ).
• There are many fixed port used in unit-test (e.g. 10001, 30000), and this might cause port conflict.
• Some unit-test may affect others while haven't clean up environment in time. ( e.g. ConditionalEventListenerTest.testOnEvent added OnlyHelloWorldEventListener and EventDispatcherTest.testDefaultMethods requires empty lisitener )
• Hessian2 is unable to correctly serialize byte. ( e.g. EnumBak.testNormal )
• In callback parameter test ( ExplicitCallbackTest ), the provider is unable to get the method, which is Null ( line 288 ) , when DubboInvokerAvilableTest using ProtocolUtils to export somethings. ( Howerver both ExplicitCallbackTest and DubboInvokerAvilableTest can run correctly separately )

For CodeGenerator, I think it is inevitable to adapt separately for Windows and Linux platform which have quite different way to manage line speration.

In source code of AdaptiveClassCodeGenerator, it is really use '\n' only.

package org.apache.dubbo.common.extension;

/**
 * Code generator for Adaptive class
 */
public class AdaptiveClassCodeGenerator {

    private static final String CODE_METHOD_DECLARATION = "public %s %s(%s) %s {\n%s}\n";

    ...

    /**
     * generate method declaration
     */
    private String generateMethod(Method method) {
        String methodReturnType = method.getReturnType().getCanonicalName();
        String methodName = method.getName();
        String methodContent = generateMethodContent(method);
        String methodArgs = generateMethodArguments(method);
        String methodThrows = generateMethodThrows(method);
        return String.format(CODE_METHOD_DECLARATION, methodReturnType, methodName, methodArgs, methodThrows, methodContent);
    }

}

However, when reading files from filesystem on Windows, the result always contains '\r'.

So, I try to fix it and leave a comment by the following way.

public class AdaptiveClassCodeGeneratorTest {

    @Test
    public void testGenerate() throws IOException {
        AdaptiveClassCodeGenerator generator = new AdaptiveClassCodeGenerator(HasAdaptiveExt.class, "adaptive");
        String value = generator.generate();
        URL url = getClass().getResource("/org/apache/dubbo/common/extension/adaptive/HasAdaptiveExt$Adaptive");
        try (InputStream inputStream = url.openStream()) {
            String content = IOUtils.read(new InputStreamReader(inputStream, StandardCharsets.UTF_8));
            // Content getting from resource in Windows platform contains '\r' delimiter
            content = content.replaceAll("\r","");
            assertTrue(content.contains(value));
        }
    }
}

Also, I think it is feasible to compile generator's result in runtime and compare it to resource from source.

[xiantang]

@AlbumenJ you can create a PR to fix this testcase issue

[AlbumenJ]

5913 Already create PR

[htynkn]

close via #5913
Thanks for @AlbumenJ 's great work