It completely depends how Resolver is created and how/when a Wagon
instance is created. If Resolver exists once during a Maven session and
hopefully Wagon only once, but I don't know. Another issue with the
current code is that the client is never properly shut down. I.e.g, no
sockets are freed and the peer has to handle broken connections.
M
Am 2020-05-17 um 23:42 schrieb Olivier Lamy:
Oh Yes I agree the current API would need major (breaking?) changes.
But openConnectionInternal creating client would not reuse http connection
(or you have another idea?)
It was a bit of hackish to have http connection pooling due to current
design but especially with https it saves some IO.
On Mon, 18 May 2020 at 01:53, Michael Osipov <micha...@apache.org> wrote:
Alex, I will get back to you in a couple of days because it is a lot of
work. But already agree, the current approach in Wagon makes it
impossible to hook in TLS mutual auth and #openConnectionInternal() must
create the client upon call.
M
Am 2020-05-17 um 17:31 schrieb Alex O'Ree:
Pinging you back again on this. Adding support for this (i think) it
going
to require some significant changes to the abstract http client wagon
class. Client certificate authentication, on a per endpoint basis,would
require separate ssl socket factories, which is constructed before the
pooling http client connection manager. Having everything static makes
this
difficult to implement without potentially breaking any other plugin that
uses this class programmatically. Would perhaps changing
'openConnectionInternal' be a better option for hooking this? I.e. if we
have a user defined key/trust setup, make a new configuration within this
method, otherwise fallback to the default static pool?
On Mon, May 11, 2020 at 7:10 PM Alex O'Ree <alexo...@apache.org> wrote:
I did some work on this over the weekend. Maintaining backwards
compatibility is going to be challenging due to the http connection pool
being static. Since the http client now needs to be specific to a
repository or destination, i'm not sure if that configuration will still
work. Anyhow, i ended up down a rat role of trying to understand why
some
of the unit tests were failing and making it worse in the process.
On Wed, May 6, 2020 at 6:38 AM Michael Osipov <micha...@apache.org>
wrote:
Am 2020-05-05 um 22:03 schrieb Alex O'Ree:
I was looking over the docs for the settings.xml file and noted that
it
looks like it's possible to access a nexus repository using a client
certificate of sorts. It's not clear the docs if a JKS can be used or
if it
must be a ssh private key or what.
http://maven.apache.org/settings.html#servers
I wanted to confirm that the linked docs is still accurate? I have a
few
different use cases and may need to reference a client cert key pair
in
a
JKS or perhaps from the windows certificate store for authentication
to
the
nexus repository. Is still a supported configuration by maven? I found
some
references to support here:
https://issues.apache.org/jira/browse/MNG-1560
which references setting maven options for javax.net.ssl.* settings.
Considering the environment, i'll probably need to be able to specify
the
key alias name too, just in case there's multiple certificates
available.
MNG-5583. I have intentionally closed this one since no was willing to
work on it. If someone wants to work on it, I'd be happy to discuss.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
