The application explicitly uses wagon, I should have mentioned that. It
extends the RepositorySystemSupplier to set it as one of the transports and
the provider is really simple, it just overrides the lookup method like
this (the class loader hack is in place):
@Override
public Wagon lookup(String roleHint) throws Exception {
final Thread currentThread = currentThread();
final ClassLoader originalClassLoader = currentThread.getContextClassLoader();
currentThread.setContextClassLoader(null);
try {
if ("https".equals(roleHint)) {
return new HttpWagon();
} else if ("http".equals(roleHint)) {
return new HttpWagon();
}
throw new IllegalArgumentException("No wagon available for " + roleHint);
} finally {
currentThread.setContextClassLoader(originalClassLoader);
}
}
And we also have an implementation of WagonConfigurator with some custom
configurations. I just came across this wagon thing and I'm reading about
it, should I be able to fully replace it with the new default transport
given that get, head, and put methods are neglected by it?
On Thu, Nov 2, 2023 at 7:47 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> Hi Rodrigo,
>
> If you have "that uses maven programmatically to resolve dependencies" and
> you updated it to Maven 3.9.4, then there is something more you have, as
> Maven 3.9 demotes wagon as "primary" transport. Given your analysis still
> shows wagon classes, it means your code explicitly uses Wagon. Can you
> share some source maybe?
>
> Thanks
> T
>
>
> On Thu, Nov 2, 2023, 23:09 Rodrigo Bourbon <rbour...@salesforce.com
> .invalid>
> wrote:
>
> > Hi, I have an application that uses maven programmatically to resolve
> > dependencies and I noticed that the class loader used to load the maven
> and
> > maven-resolver artifacts is being retained in memory because of the
> > connection manager created in
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.createConnManager()
> > while getting the SSLSocketFactory
> > <
> https://github.com/apache/maven-wagon/blob/wagon-3.4.2/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L384
> >.
> > To fix it I set the context class loader to null before creating the
> > HttpWagon and it worked partially. I no longer get a strong reference on
> > my class loader but I see it in "Pending finalization" state forever, so
> > it's never actually deallocated. The reason seems to be an SSL socket
> that
> > it's not being closed properly as shown in the image below.
> > [image: image.png]
> >
> > After searching where that socket comes from I see that it's again
> related
> > to the AbstractHttpClientWagon while executing metadata resolution, but I
> > can't manage to find when it's being leaked.
> > This started happening after I changed to newer versions, I'm using
> maven-resolver
> > 1.9.15 and maven 3.9.4 and previously I was using aether 1.0.2.v20150114
> > and maven 3.3.9.
> >
> > Any ideas on what might be going on? Thanks in advance.
> >
>
