Re: JUnit 5 upgrade rant (contains obscene language)
If you'd like, I could run `git-bisect` to figure out where the tests broke; I'll just need to know which tests broke and how to run them. On Sat, Oct 22, 2022 at 8:14 AM Oleg Kalnichevski wrote: > The JUnit 5 upgrade was a cluster. > > The original contributor ported some of the easy test cases that did > not have a complex resource setup and left most complex and most > important protocol and integration tests still partially using JUnit 4 > features through the JUnit 5 migration layer. I cannot blaim him. JUnit > 5 after so many years still have no reasonable way of parameterizing > test cases through constructors. What the original contributor did not > do (by mistake or by oversight) is activating the vintage JUnit support > for Maven Surefire plugin. > > As a result we have been running CI of the 5.2 code _without_ > integration tests for a _whole_ year (since Nov 2021). > > In the meantime two integration tests regressed and I have no idea at > what point it has happended and what might have broken them. > > It is too late to go back to JUnit 4. I have migrated the remaining > test cases still using the migration support layer. Those test cases > got more verbose and uglier but at least they work as intended with > JUnit 5. > > This is a prime example that of one uses newer, supposedly better > frameworks, without any particular practical reason, one ends up with > things not being better, but just different. > > Oleg > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: JUnit 5 upgrade rant (contains obscene language)
assertThrows is available in JUnit 4.13. On Sun, Oct 23, 2022 at 4:11 AM Gary Gregory wrote: > Version 5 has some drawbacks but on the positive side, APIs like > assertThrows are very useful. > > Gary > > On Sun, Oct 23, 2022, 04:31 Michael Osipov wrote: > > > Am 2022-10-22 um 17:14 schrieb Oleg Kalnichevski: > > > The JUnit 5 upgrade was a cluster. > > > > > > The original contributor ported some of the easy test cases that did > > > not have a complex resource setup and left most complex and most > > > important protocol and integration tests still partially using JUnit 4 > > > features through the JUnit 5 migration layer. I cannot blaim him. JUnit > > > 5 after so many years still have no reasonable way of parameterizing > > > test cases through constructors. What the original contributor did not > > > do (by mistake or by oversight) is activating the vintage JUnit support > > > for Maven Surefire plugin. > > > > > > As a result we have been running CI of the 5.2 code _without_ > > > integration tests for a _whole_ year (since Nov 2021). > > > > That is really sad. I have also noticed that people uprading these days > > for the sake of upgrading instead of real improvements. > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > >
[jira] [Commented] (HTTPCLIENT-2241) HttpResponseInterceptor is never called on errors
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622875#comment-17622875
]
Patrick Barry commented on HTTPCLIENT-2241:
---
Upon further research, I found hitting a website that exists but a path that
does not, does result in 400 and goes through response interceptor. If you
provide a url of a site that does not exists, it results in exception being
thrown and response interceptor not hit. I can work around this. Thanks.
> HttpResponseInterceptor is never called on errors
> -
>
> Key: HTTPCLIENT-2241
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2241
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 4.5.13
>Reporter: Patrick Barry
>Priority: Major
>
> We are registering two interceptors for logging purposes. One for request and
> response. Our response Interceptor is never called when we encounter an
> error, like a 404. Is there another interceptor or way to capture this info
> or is this a bug. We are using Jersey with Apache client under the covers.
> Here is a unit test that that requires Slf4j, logback and apache http client.
> {code:java}
> @Test
> public void testResponseLoggingInterceptor2(){
> Logger logger = (Logger)
> LoggerFactory.getLogger(ResponseLoggingInterceptor.class);
> // create and start a ListAppender
> ListAppender listAppender = new ListAppender<>();
> listAppender.start();
> // add the appender to the logger
> logger.addAppender(listAppender);
> ClientConfig clientConfig = new ClientConfig();
> clientConfig.connectorProvider(new ApacheConnectorProvider());
> Client client = ClientBuilder.newBuilder().withConfig(clientConfig).build();
> client.register((ApacheHttpClientBuilderConfigurator) httpClientBuilder ->
> httpClientBuilder
> .addInterceptorLast(new RequestLoggingInterceptor())
> .addInterceptorFirst(new ResponseLoggingInterceptor()));//This is never hit
> when hitting endpoint that does not exists
> try {
> WebTarget target = client.target("https://localhost:8080/not/exists;);
> Response response = target.request("application/json").get();
> }catch (Exception ignored){
> //nothing
> }
> List logsList = listAppender.list;
> assertEquals("test message", logsList.get(0).getFormattedMessage());
> }{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-2240) ProxyClient always throws ProtocolException
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-2240.
---
Fix Version/s: 5.1.4
5.2-beta2
Resolution: Fixed
Fixed in 5.1.x and master.
Oleg
> ProxyClient always throws ProtocolException
> ---
>
> Key: HTTPCLIENT-2240
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2240
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.1.3
>Reporter: Rostyslav Smirnov
>Priority: Major
> Fix For: 5.1.4, 5.2-beta2
>
>
> When setting up HTTP proxy tunnel using ProxyClient, the following exception
> is thrown:
>
> {code:java}
> Exception in thread "main" org.apache.hc.core5.http.ProtocolException: Target
> host is unknown
> at
> org.apache.hc.core5.http.protocol.RequestTargetHost.process(RequestTargetHost.java:77)
> at
> org.apache.hc.core5.http.protocol.DefaultHttpProcessor.process(DefaultHttpProcessor.java:107)
> at
> org.apache.hc.core5.http.impl.io.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:246)
> at
> org.apache.hc.client5.http.impl.classic.ProxyClient.tunnel(ProxyClient.java:174)
> at ProxyClientTest.main(ProxyClientTest.java:7){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2240) ProxyClient always throws ProtocolException
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622853#comment-17622853
]
ASF subversion and git services commented on HTTPCLIENT-2240:
-
Commit b5a90d57da7abd10c36ffa8198b3080a487336c9 in httpcomponents-client's
branch refs/heads/5.1.x from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=b5a90d57d ]
HTTPCLIENT-2240: fixed incorrect CONNECT method initialization in ProxyClient
> ProxyClient always throws ProtocolException
> ---
>
> Key: HTTPCLIENT-2240
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2240
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.1.3
>Reporter: Rostyslav Smirnov
>Priority: Major
>
> When setting up HTTP proxy tunnel using ProxyClient, the following exception
> is thrown:
>
> {code:java}
> Exception in thread "main" org.apache.hc.core5.http.ProtocolException: Target
> host is unknown
> at
> org.apache.hc.core5.http.protocol.RequestTargetHost.process(RequestTargetHost.java:77)
> at
> org.apache.hc.core5.http.protocol.DefaultHttpProcessor.process(DefaultHttpProcessor.java:107)
> at
> org.apache.hc.core5.http.impl.io.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:246)
> at
> org.apache.hc.client5.http.impl.classic.ProxyClient.tunnel(ProxyClient.java:174)
> at ProxyClientTest.main(ProxyClientTest.java:7){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2240) ProxyClient always throws ProtocolException
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622851#comment-17622851
]
ASF subversion and git services commented on HTTPCLIENT-2240:
-
Commit ba45d80b072072be322d49835659f20b32bf2fb0 in httpcomponents-client's
branch refs/heads/master from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=ba45d80b0 ]
HTTPCLIENT-2240: fixed incorrect CONNECT method initialization in ProxyClient
> ProxyClient always throws ProtocolException
> ---
>
> Key: HTTPCLIENT-2240
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2240
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.1.3
>Reporter: Rostyslav Smirnov
>Priority: Major
>
> When setting up HTTP proxy tunnel using ProxyClient, the following exception
> is thrown:
>
> {code:java}
> Exception in thread "main" org.apache.hc.core5.http.ProtocolException: Target
> host is unknown
> at
> org.apache.hc.core5.http.protocol.RequestTargetHost.process(RequestTargetHost.java:77)
> at
> org.apache.hc.core5.http.protocol.DefaultHttpProcessor.process(DefaultHttpProcessor.java:107)
> at
> org.apache.hc.core5.http.impl.io.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:246)
> at
> org.apache.hc.client5.http.impl.classic.ProxyClient.tunnel(ProxyClient.java:174)
> at ProxyClientTest.main(ProxyClientTest.java:7){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Re: JUnit 5 upgrade rant (contains obscene language)
Version 5 has some drawbacks but on the positive side, APIs like assertThrows are very useful. Gary On Sun, Oct 23, 2022, 04:31 Michael Osipov wrote: > Am 2022-10-22 um 17:14 schrieb Oleg Kalnichevski: > > The JUnit 5 upgrade was a cluster. > > > > The original contributor ported some of the easy test cases that did > > not have a complex resource setup and left most complex and most > > important protocol and integration tests still partially using JUnit 4 > > features through the JUnit 5 migration layer. I cannot blaim him. JUnit > > 5 after so many years still have no reasonable way of parameterizing > > test cases through constructors. What the original contributor did not > > do (by mistake or by oversight) is activating the vintage JUnit support > > for Maven Surefire plugin. > > > > As a result we have been running CI of the 5.2 code _without_ > > integration tests for a _whole_ year (since Nov 2021). > > That is really sad. I have also noticed that people uprading these days > for the sake of upgrading instead of real improvements. > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
[jira] [Commented] (HTTPCLIENT-2241) HttpResponseInterceptor is never called on errors
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622778#comment-17622778
]
Oleg Kalnichevski commented on HTTPCLIENT-2241:
---
[~patrickjamesbarry] I am not sure I understand the problem. This works for me.
{code:java}
CloseableHttpClient httpclient = HttpClients.custom()
.addInterceptorFirst(new HttpResponseInterceptor() {
@Override
public void process(HttpResponse httpResponse, HttpContext
httpContext) throws HttpException, IOException {
System.out.println("Got response: " + httpResponse);
}
})
.build();
try {
HttpGet httpget = new HttpGet("http://httpbin.org/huh;);
System.out.println("Executing request " + httpget.getRequestLine());
// Pass local context as a parameter
CloseableHttpResponse response = httpclient.execute(httpget);
try {
System.out.println("");
System.out.println(response.getStatusLine());
EntityUtils.consume(response.getEntity());
} finally {
response.close();
}
} finally {
httpclient.close();
}
{code}
{noformat}
Executing request GET http://httpbin.org/huh HTTP/1.1
Got response: HttpResponseProxy{HTTP/1.1 404 NOT FOUND [Date: Sun, 23 Oct 2022
10:35:41 GMT, Content-Type: text/html, Content-Length: 233, Connection:
keep-alive, Server: gunicorn/19.9.0, Access-Control-Allow-Origin: *,
Access-Control-Allow-Credentials: true] ResponseEntityProxy{[Content-Type:
text/html,Content-Length: 233,Chunked: false]}}
HTTP/1.1 404 NOT FOUND
{noformat}
Oleg
> HttpResponseInterceptor is never called on errors
> -
>
> Key: HTTPCLIENT-2241
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2241
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 4.5.13
>Reporter: Patrick Barry
>Priority: Major
>
> We are registering two interceptors for logging purposes. One for request and
> response. Our response Interceptor is never called when we encounter an
> error, like a 404. Is there another interceptor or way to capture this info
> or is this a bug. We are using Jersey with Apache client under the covers.
> Here is a unit test that that requires Slf4j, logback and apache http client.
> {code:java}
> @Test
> public void testResponseLoggingInterceptor2(){
> Logger logger = (Logger)
> LoggerFactory.getLogger(ResponseLoggingInterceptor.class);
> // create and start a ListAppender
> ListAppender listAppender = new ListAppender<>();
> listAppender.start();
> // add the appender to the logger
> logger.addAppender(listAppender);
> ClientConfig clientConfig = new ClientConfig();
> clientConfig.connectorProvider(new ApacheConnectorProvider());
> Client client = ClientBuilder.newBuilder().withConfig(clientConfig).build();
> client.register((ApacheHttpClientBuilderConfigurator) httpClientBuilder ->
> httpClientBuilder
> .addInterceptorLast(new RequestLoggingInterceptor())
> .addInterceptorFirst(new ResponseLoggingInterceptor()));//This is never hit
> when hitting endpoint that does not exists
> try {
> WebTarget target = client.target("https://localhost:8080/not/exists;);
> Response response = target.request("application/json").get();
> }catch (Exception ignored){
> //nothing
> }
> List logsList = listAppender.list;
> assertEquals("test message", logsList.get(0).getFormattedMessage());
> }{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Re: JUnit 5 upgrade rant (contains obscene language)
Am 2022-10-22 um 17:14 schrieb Oleg Kalnichevski: The JUnit 5 upgrade was a cluster. The original contributor ported some of the easy test cases that did not have a complex resource setup and left most complex and most important protocol and integration tests still partially using JUnit 4 features through the JUnit 5 migration layer. I cannot blaim him. JUnit 5 after so many years still have no reasonable way of parameterizing test cases through constructors. What the original contributor did not do (by mistake or by oversight) is activating the vintage JUnit support for Maven Surefire plugin. As a result we have been running CI of the 5.2 code _without_ integration tests for a _whole_ year (since Nov 2021). That is really sad. I have also noticed that people uprading these days for the sake of upgrading instead of real improvements. - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
