Leak de classloader en HttpsConnection en fire-client-java

[antonireus]

Fijar el defaultHostnameVerifier en la classe es.gob.fire.client.HttpsConnection provoca un "leak" de classloader.

Cuando se carga una aplicación WAR que incorpore fire-client-java esta se carga con un classloader específico. Al ejecutar el HttpsConnection.getConnection las líneas 311-316:

        HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
            @Override
            public boolean verify(final String hostname, final SSLSession session) {
                return true;
            }
        });

esto provoca que la clase anónima, cargada mediante el classloader específico del WAR este referenciada por HttpsURLConnection. Al hacer un undeploy del WAR, esa referencia se mantiene, dado que las clases mantienen una referencia al classloader con que han sido cargados, eso evita que el GC pueda procesar el classloader del WAR.

Por otro lado, tanto esa línea, como la anterior, que ejecuta HttpsURLConnection.setDefaultSSLSocketFactory(this.ctx.getSocketFactory()); no deberian ser necesarias, puesto que tanto el SSLSocketFactory como el HostnameVerifier se registran en la connexión creada en las líneas siguientes,

        ((HttpsURLConnection) con).setSSLSocketFactory(this.ctx.getSocketFactory());
        ((HttpsURLConnection) con).setHostnameVerifier(new HostnameVerifier() {
            @Override
            public boolean verify(final String hostname, final SSLSession session) {
                return true;
            }
        });

[antonireus]

Lo mismo pasa con la fijar el defaultSSLSocketFactory si se ha fijado el valor all en la propiedad javax.net.ssl.trustStore, puesto que el SSLSocketFactory se construye con una referencia al a classe anónima de tipo X509TrustManager guardado en DUMMY_TRUST_MANAGER.

Dado que como se ha dicho en las lineas siguientes se fija el SSLSocketFactory específico para la conexión no tiene sentido fijar el defaultSSLSocketFactory

[Gamuci]

Corregido. Gracias por el aviso.