Descripción del problema
Al utilizar la librería culqi-java versión 2.0.4 en un proyecto basado en Spring Boot 3.x (Spring Framework 6.x), la aplicación falla al arrancar con un NoSuchMethodError relacionado con SpringFactoriesLoader.forDefaultResourceLocation(ClassLoader).
Este método está presente en Spring 6.x, pero al parecer la librería culqi-java incluye (por sombreado/shading) clases antiguas de Spring que no cuentan con dicho método.
En tiempo de ejecución, la JVM termina cargando la clase SpringFactoriesLoader desde culqi-java-v2.0.4.jar en lugar de la versión adecuada de Spring 6.x que mi aplicación usa. Esto da lugar a la excepción:
Exception in thread "main" java.lang.NoSuchMethodError:
'org.springframework.core.io.support.SpringFactoriesLoader
org.springframework.core.io.support.SpringFactoriesLoader.forDefaultResourceLocation(java.lang.ClassLoader)'
...
at com.fredgar.pe.mspayment.MsPaymentApplication.main(MsPaymentApplication.java:10)
Pasos para reproducirlo
-
Crear un proyecto con Spring Boot 3.x (ej. 3.4.4 o 3.1.4) y Java 17/21.
-
Añadir la dependencia de culqi-java v2.0.4:
<dependency>
<groupId>com.github.culqi</groupId>
<artifactId>culqi-java</artifactId>
<version>v2.0.4</version>
</dependency>
-
Ejecutar mvn clean package y luego java -jar target/myapp.jar.
-
Al arrancar, salta el NoSuchMethodError antes mencionado.
Diagnóstico
Haciendo java -verbose:class -jar myapp.jar | grep SpringFactoriesLoader, se observa que la clase SpringFactoriesLoader se carga desde culqi-java-v2.0.4.jar, en lugar de cargarse desde spring-core-6.2.x.jar.
En el pom.xml de culqi-java se usa maven-shade-plugin y se incluyen dependencias de Spring Data 2.7.x, lo cual arrastra clases más antiguas de Spring que terminan "sombreadas" dentro del jar final.
Estas clases antiguas no tienen el método forDefaultResourceLocation(ClassLoader), introducido en Spring 6.x, provocando la excepción.
Posibles soluciones/propuestas
-
Actualizar la dependencia de Spring Data a una versión compatible con Spring Boot 3.x (por ejemplo, 3.0.x o 3.1.x) y regenerar el jar sin incluir clases antiguas de Spring en el shading.
-
Ofrecer un artefacto de culqi-java que no empaquete (shade) clases de Spring, de modo que el proyecto principal use directamente las versiones adecuadas de Spring.
-
Retirar o modularizar la necesidad de Spring en culqi-java, para evitar colisiones de versiones en proyectos que ya usan Spring.
Entorno
- JDK: 21 (pero también ocurre en 17)
- Maven 3.8.x
- Spring Boot: 3.4.4 (Spring Framework 6.2.5)
- culqi-java v2.0.4
Muchas gracias de antemano por revisar este tema. Quedo atento si se requiere más información. Si existe una versión o rama que no sombree Spring, por favor indíquenmelo. Cualquier actualización que alinee culqi-java con Spring 3.x/6.x ayudará mucho a evitar conflictos de versiones.
Descripción del problema
Al utilizar la librería
culqi-javaversión 2.0.4 en un proyecto basado en Spring Boot 3.x (Spring Framework 6.x), la aplicación falla al arrancar con unNoSuchMethodErrorrelacionado conSpringFactoriesLoader.forDefaultResourceLocation(ClassLoader).Este método está presente en Spring 6.x, pero al parecer la librería
culqi-javaincluye (por sombreado/shading) clases antiguas de Spring que no cuentan con dicho método.En tiempo de ejecución, la JVM termina cargando la clase
SpringFactoriesLoaderdesdeculqi-java-v2.0.4.jaren lugar de la versión adecuada de Spring 6.x que mi aplicación usa. Esto da lugar a la excepción:Pasos para reproducirlo
Crear un proyecto con Spring Boot 3.x (ej. 3.4.4 o 3.1.4) y Java 17/21.
Añadir la dependencia de culqi-java v2.0.4:
Ejecutar
mvn clean packagey luegojava -jar target/myapp.jar.Al arrancar, salta el
NoSuchMethodErrorantes mencionado.Diagnóstico
Haciendo
java -verbose:class -jar myapp.jar | grep SpringFactoriesLoader, se observa que la claseSpringFactoriesLoaderse carga desdeculqi-java-v2.0.4.jar, en lugar de cargarse desdespring-core-6.2.x.jar.En el
pom.xmlde culqi-java se usamaven-shade-pluginy se incluyen dependencias de Spring Data 2.7.x, lo cual arrastra clases más antiguas de Spring que terminan "sombreadas" dentro del jar final.Estas clases antiguas no tienen el método
forDefaultResourceLocation(ClassLoader), introducido en Spring 6.x, provocando la excepción.Posibles soluciones/propuestas
Actualizar la dependencia de Spring Data a una versión compatible con Spring Boot 3.x (por ejemplo, 3.0.x o 3.1.x) y regenerar el jar sin incluir clases antiguas de Spring en el shading.
Ofrecer un artefacto de culqi-java que no empaquete (shade) clases de Spring, de modo que el proyecto principal use directamente las versiones adecuadas de Spring.
Retirar o modularizar la necesidad de Spring en culqi-java, para evitar colisiones de versiones en proyectos que ya usan Spring.
Entorno
Muchas gracias de antemano por revisar este tema. Quedo atento si se requiere más información. Si existe una versión o rama que no sombree Spring, por favor indíquenmelo. Cualquier actualización que alinee culqi-java con Spring 3.x/6.x ayudará mucho a evitar conflictos de versiones.