NoSuchMethodError: 'java.util.SortedMap org.webjars.WebJarAssetLocator.getFullPathIndex'

szczebel commented 2 years ago

Hey,

So here's what I'm seeing in the logs after visiting localhost:8080, same when running from jproRun or jproRelease -> start.bat

! @7mjele238 - Internal server error, for (GET) [/jpro/js/jpro.js] ->

play.api.UnexpectedException: Unexpected exception[RuntimeException: java.lang.NoSuchMethodError: 'java.util.SortedMap org.webjars.WebJarAssetLocator.getFullPathIndex(java.util.regex.Pattern, java.lang.ClassLoader[])']
        at play.api.http.HttpErrorHandlerExceptions$.throwableToUsefulException(HttpErrorHandler.scala:358)
        at play.api.http.DefaultHttpErrorHandler.onServerError(HttpErrorHandler.scala:264)
        at play.core.server.AkkaHttpServer$$anonfun$2.applyOrElse(AkkaHttpServer.scala:430)
        at play.core.server.AkkaHttpServer$$anonfun$2.applyOrElse(AkkaHttpServer.scala:422)
        at scala.concurrent.Future.$anonfun$recoverWith$1(Future.scala:417)
        at scala.concurrent.impl.Promise.$anonfun$transformWith$1(Promise.scala:41)
        at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
        at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:63)
        at akka.dispatch.BatchingExecutor$BlockableBatch.$anonfun$run$1(BatchingExecutor.scala:100)
        at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
Caused by: java.lang.RuntimeException: java.lang.NoSuchMethodError: 'java.util.SortedMap org.webjars.WebJarAssetLocator.getFullPathIndex(java.util.regex.Pattern, java.lang.ClassLoader[])'
        at play.api.mvc.ActionBuilder$$anon$9.apply(Action.scala:384)
        at play.api.mvc.Action.$anonfun$apply$4(Action.scala:82)
        at play.api.libs.streams.StrictAccumulator.$anonfun$mapFuture$4(Accumulator.scala:168)
        at scala.util.Try$.apply(Try.scala:213)
        at play.api.libs.streams.StrictAccumulator.$anonfun$mapFuture$3(Accumulator.scala:168)
        at scala.Function1.$anonfun$andThen$1(Function1.scala:57)
        at scala.Function1.$anonfun$andThen$1(Function1.scala:57)
        at scala.Function1.$anonfun$andThen$1(Function1.scala:57)
        at play.api.libs.streams.StrictAccumulator.run(Accumulator.scala:199)
        at play.core.server.AkkaHttpServer.$anonfun$runAction$4(AkkaHttpServer.scala:417)
Caused by: java.lang.NoSuchMethodError: 'java.util.SortedMap org.webjars.WebJarAssetLocator.getFullPathIndex(java.util.regex.Pattern, java.lang.ClassLoader[])'
        at org.webjars.play.WebJarsUtil.webJarAssetLocator$lzycompute(WebJarsUtil.scala:105)
        at org.webjars.play.WebJarsUtil.org$webjars$play$WebJarsUtil$$webJarAssetLocator(WebJarsUtil.scala:103)
        at org.webjars.play.WebJarsUtil.$anonfun$fullPath$1(WebJarsUtil.scala:152)
        at scala.util.Try$.apply(Try.scala:213)
        at org.webjars.play.WebJarsUtil.fullPath(WebJarsUtil.scala:152)
        at controllers.jpro.jprojsString$lzycompute(jpro.scala:83)
        at controllers.jpro.jprojsString(jpro.scala:82)
        at controllers.jpro.jprojshash$lzycompute(jpro.scala:120)
        at controllers.jpro.jprojshash(jpro.scala:120)
        at controllers.jpro.$anonfun$jprojs$1(jpro.scala:122)

System information:

JPro will be started.
[info] a.e.s.Slf4jLogger - Slf4jLogger started
[info] play.api.Play - Application started (Prod) (no global state)
[info] p.c.s.AkkaHttpServer - Enabling HTTP/2 on Akka HTTP server...
[info] p.c.s.AkkaHttpServer - Listening for HTTP on /[0:0:0:0:0:0:0:0]:8080
[warn] javafx - Unsupported JavaFX configuration: classes were loaded from 'unnamed module @7a77b11d'
[info] c.jpro.activity - Starting the server
[info] c.j.i.s.Initializer$ -  *** Starting JPro: https://www.jpro.one/ ***
[info] c.j.i.s.Initializer$ - OS: Windows 10
[info] c.j.i.s.Initializer$ - JPro: 2021.2.3
[info] c.j.i.s.Initializer$ - Java version: 17
[info] c.j.i.s.Initializer$ - JVM: 17 Oracle Corporation
[info] c.j.i.s.Initializer$ - JavaFX jar: file:/C:/Users/[...]/jfx/win/javafx-graphics-17.0.1.2-jpro+0-win.jar
[info] c.j.i.s.Initializer$ - redirected OUT / ERR
[info] c.j.i.s.Initializer$ - installed SLF4JBridge
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by com.jpro.internal.server.Initializer$ (file:/C:/Users/[...]/jprolibs/jpro-jvm_2.12-2021.2.3.jar)
WARNING: Please consider reporting this to the maintainers of com.jpro.internal.server.Initializer$
WARNING: System::setSecurityManager will be removed in a future release
[info] c.j.i.s.Initializer$ - JavaFX version: 17.0.1.2-jpro+0-2022-01-27-143449
[info] c.j.i.s.Initializer$ - finished init!

Any idea what's wrong? Maybe Java 17 is not supported yet - in such case what's the ETA?

Side questions:

I have multi-module gradle build (root project with few child projects: backend, frontend, the latter is the jpro app. Where should I place the jpro.conf file? tried under root and frontend, to no avail.
I'm using gradle-kotlin (.kts) as build system. jpro{} configuration is not recognized (.kts does not compile, 'Unresolved reference: jpro'). Any hints?

Thanks, Adam

szczebel commented 2 years ago

updates:

Please disregard the question about jpro.conf, added to /resources, all OK.
Java 17 seems not to be an issue, as I was able to successfully run HelloJPro sample app on my machine

FlorianKirmaier commented 2 years ago

Thank you for the Bugreport!

JPro supports Java17, so that shouldn't be the issue. We don't properly support the gradle kotlin dsl - which is something we should focus on now. But because you got it running, it shouldn't be the problem.

It looks like a resource is missing for some reason.

Having a multi-module project as you've described should be fine, and is also our usual setup. Which Gradle version are you using? The same GradleVersion works fine with the HelloWorld project, right? Are you maybe using Scala in your project? JPro is internally using Scala, so maybe it confuses the dependency resolution of JPro.

If these questions don't give us a hint, I would have to ask you to minify your project until you find the trigger of the problem. What happens if you remove all dependencies of the JPro project?

szczebel commented 2 years ago

Hey @FlorianKirmaier ,

I nailed down the issue, here's what happened:

JPro itself depends on webjars-locator-core-0.37.jar, as can be seen in build\distributions\HelloJPro-jpro.zip\jprolibs after running jproRelease
my application uses spring-boot, so I have spring dependency management enabled in gradle
spring dependency management BOM declares that webjars-locator-core will be of version 0.48
my app does NOT depend on webjars-locator-core (neither directly nor transitively), but:
...during build, jpro plugin picks up 0.48 and puts it in \jprolibs instead of 0.37; jproRun also uses this version
and apparently those two versions are not compatible (getFullPathIndex() method was removed or changed signature?), so JPro runtime cannot do its job and breaks

Workaround for my particular issue is quite simple, I just needed to add extra["webjars-locator-core.version"] = "0.37" to my gradle.build.kts, as my app doesn't use webjars, so I don't have to care.

This is not a proper fix in general though - I guess you'll be seeing similar issues whenever an app will be using dependency management that will conflict with any of 138 jars that you have in \jprolibs - which is quite likely I suppose?

I'm guessing a proper fix would need to be done somewhere in jpro gradle plugin:

to force using your required dependency versions for anything that goes to \jprolibs
but also to ensure that you don't override the versions of app's dependencies (that go to \libs)

And JPro runtime should be using separate classloaders:

one for its own runtime and dependencies
another for the application's code and dependencies (I hope this is already implemented like so, otherwise we're in 90s dll-hell :>)

In case it's useful, reproducer repo (based on HelloJPro) is here, breaking change in this commit And the fix is on FIX branch, here

Hope this helps, Adam

FlorianKirmaier commented 2 years ago

Oh, thank you for working out the details! Yes, your first steps describe what must be done. The JPro Plugin should ignore the dependency defined with the BOM. I think it's limited to when a BOM is used.

The JProRuntime already does the classloader separation which you have suggested. A very early of JPro didn't have separated classloaders, and it was indeed a jar-hell. ;) The WebServer runs in its own Classloader, and the Application runs in the same Classloader, as it would do as a Desktop application.

JPro-one / JPro-Tickets

NoSuchMethodError: 'java.util.SortedMap org.webjars.WebJarAssetLocator.getFullPathIndex' #119