Simliar to https://bz.apache.org/bugzilla/show_bug.cgi?id=66206 I re-ran the tests on a non-English PC and found a total of two unit tests which are failing, because of expected value was hard-coded as en and actual value was not. BUT `org.apache.coyote.http2.TestHttp2Limits#testSettingsOverheadLimits`,I don't know know how to fix the problem of it. Another problematic test is following one: org.apache.coyote.http2.TestFlowControl#testNotFound Testcase: testNotFound[0: loop [0], useAsyncIO[false]] took 0.462 sec FAILED expected:<...ontent-language]-[zh[]] 3-Header-[content-...> but was:<...ontent-language]-[zh[-CN]] 3-Header-[content-...> junit.framework.AssertionFailedError: expected:<...ontent-language]-[zh[]] 3-Header-[content-...> but was:<...ontent-language]-[zh[-CN]] 3-Header-[content-...> The reason for this is that we should get the default local through StringManager, not directly through Locale.getDefault(), and the toLanguageTag method is used when setting the local of request, so we should be consistent here as well.
(In reply to HanLi from comment #0) > The reason for this is that we should get the default local through > StringManager, not directly through Locale.getDefault(), and the > toLanguageTag method is used when setting the local of request, so we should > be consistent here as well. Sorry, there is a mistake here, set the local of the response, not the local of the request
(In reply to HanLi from comment #0) > BUT `org.apache.coyote.http2.TestHttp2Limits#testSettingsOverheadLimits`,I > don't know know how to fix the problem of it. Aha! I found that Mark had solved a similar problem before, so I referenced his implementation. ;)
I think we have a number of options here: 1. (Similar to my previous 'fixes') reduce the text tested to that which doesn't change depending on locale. 2. Force the unit tests to run under en-US. 3. Use StringManager to retrieve the expected txt in the current locale and then compare the actual output to the locale specific expected text. My concern with 1 is that sometimes we may skip testing parts of the output that are relevant and miss bugs as a result. Option 2 is sufficient to test the functionality primarily being tested whereas option 3 (sort of) tests some of the i18n as well. I'm leaning towards option 3 as it doesn't look too challenging to implement for the small number of test cases where this is an issue. We do need to make sure we distinguish between the system locale and the locale we expected to be used for the response. Thoughts?
(In reply to Mark Thomas from comment #3) > Option 2 is sufficient to test the functionality primarily being tested > whereas option 3 (sort of) tests some of the i18n as well. Agreed! I also think that option 3 is the best solution. > I'm leaning towards option 3 as it doesn't look too challenging to implement for > the small number of test cases where this is an issue. It's not too difficult to implement, and i found that the only trouble is that we may need to process the parameters in the text via regular expressions (we may not get the parameters, e.g. connectionId). So i will refix the problematic unit tests (include previous PR) according to option 3, is that OK? Han
Sounds great. Thanks.
PR: https://github.com/apache/tomcat/pull/542