arturobernalg commented on code in PR #418:
URL:
https://github.com/apache/httpcomponents-core/pull/418#discussion_r1305308816
##
httpcore5/src/main/java/org/apache/hc/core5/net/URIBuilder.java:
##
@@ -156,7 +155,7 @@ public URIBuilder setAuthority(final NamedEndpoint
authorit
arturobernalg opened a new pull request, #419:
URL: https://github.com/apache/httpcomponents-core/pull/419
Refactor `testConcurrentOperations` to use `AtomicBooleans` for outcome
verification, enhancing test determinism and reducing exception
unpredictability.
--
This is an automated mes
ok2c commented on PR #418:
URL:
https://github.com/apache/httpcomponents-core/pull/418#issuecomment-1693338496
@arturobernalg I am fine with all the proposed changes but I personally
think that `URIBuilder` should still support user info as it is not meant to be
strictly `http`/`https` spe
arturobernalg commented on PR #419:
URL:
https://github.com/apache/httpcomponents-core/pull/419#issuecomment-1693359992
> @arturobernalg Interesting. Future callbacks are deterministic but the
future itself is not?
@ok2c
With `` AtomicBoolean` ensures we can deterministically t
arturobernalg commented on PR #418:
URL:
https://github.com/apache/httpcomponents-core/pull/418#issuecomment-1693409507
> @arturobernalg I am fine with all the proposed changes but I personally
think that `URIBuilder` should still support user info as it is not meant to be
strictly `http`/
michael-o commented on PR #418:
URL:
https://github.com/apache/httpcomponents-core/pull/418#issuecomment-1693435870
> > @arturobernalg I am fine with all the proposed changes but I personally
think that `URIBuilder` should still support user info as it is not meant to be
strictly `http`/`h
dependabot[bot] opened a new pull request, #420:
URL: https://github.com/apache/httpcomponents-core/pull/420
Bumps [io.reactivex.rxjava3:rxjava](https://github.com/ReactiveX/RxJava)
from 3.1.6 to 3.1.7.
Release notes
Sourced from https://github.com/ReactiveX/RxJava/releases";>io.re
bpitman opened a new pull request, #421:
URL: https://github.com/apache/httpcomponents-core/pull/421
Note that this patch is probably incomplete - it does not break existing
tests, but no tests were added nor updated to verify the new code.
We have a need to set the InetAddress for a
ok2c commented on PR #419:
URL:
https://github.com/apache/httpcomponents-core/pull/419#issuecomment-1693665913
> Maybe I'm wrong but BasicFuture operations are inherently non-deterministic
@arturobernalg It was not my intent when I initially built `BasicFuture` but
this is likely how
arturobernalg merged PR #419:
URL: https://github.com/apache/httpcomponents-core/pull/419
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr..
bpitman commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693678024
I ran locally with `-Djapicmp.skip=true` (needed with `package`, but not
`test`). Is there a mechanism for documenting known changes to the api?
--
This is an automated mess
ok2c commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693692150
@bpitman What is exactly the intent of this change? Why do you think you
need an `InetAddress` at the request level? It is completely unclear from the
description of the PR or fro
bpitman commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693695500
See initial comment:
```
We have a need to set the InetAddress for a request - the ip tells us where
to connect and the hostname is needed for ssl verification.
```
bpitman commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693712807
Example data for a request:
```
{
"state": "RUNNING",
"status": "UP",
"name": "upload",
"hostname": "192.168.30.10",
"ip": "192.168.30.10",
"s
ok2c commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693714227
> We have a need to set the InetAddress for a request - the ip tells us
where to connect and the hostname is needed for ssl verification.
@bpitman This makes no sense at the
ok2c commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693731633
@bpitman In your particular case you do not even need any custom code. All
you need to do is to set up the connection route correctly.
```
final HttpHost target = new HttpHos
bpitman commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693765595
It would have saved me a lot of time if this had worked. Having InetAddress
in HttpHost made it seem like it supported my needs right out of the box. Look
at my changes to se
bpitman commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693771484
To be clear, I'm using httpcore5, not httpclient5. The client looks like
non-blocking wrappers around around blocking code - though, maybe just poor
examples? We can't expect
ok2c commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1693869120
> To be clear, I'm using httpcore5, not httpclient5.
@bpitman You should have started off by saying that. HttpClient has a by far
more complex and sophisticated connection m
bpitman commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1694006616
Messing around with client examples. The target ends up wrong if HttpHost
is part of the request object, but works if passed in directly to
client.execute() - as you suggested
bpitman commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1694123536
The fixes in the pr address all of these use cases using core5 directly.
client5 is still broken - it needs similar fixes (rebuild the HttpHost using
address info that had bee
garydgregory commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1694132384
Shouldn't we use builders instead of adding yet even more constructors?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log
bpitman commented on PR #421:
URL:
https://github.com/apache/httpcomponents-core/pull/421#issuecomment-1694137687
Generally, yes. This doesn't look like a typical builder pattern, though.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log o
23 matches
Mail list logo