Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Play runner failure in MacOS Big Sur #10372

Closed
zhye9452 opened this issue Jul 1, 2020 · 12 comments
Closed

Play runner failure in MacOS Big Sur #10372

zhye9452 opened this issue Jul 1, 2020 · 12 comments
Milestone

Comments

@zhye9452
Copy link

zhye9452 commented Jul 1, 2020

Play Version

2.8.2

API

Scala

Operating System

MacOS Big Sur Developer Beta Seed 1

JDK

JDK 11

Library Dependencies

Expected Behavior

  1. sbt run

Actual Behavior

  1. sbt run fails to run with below exception
[error] java.lang.UnsatisfiedLinkError: Unable to load library 'Carbon':
[error] dlopen(libCarbon.dylib, 9): image not found
[error] dlopen(libCarbon.dylib, 9): image not found
[error] 	at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:302)
[error] 	at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:455)
[error] 	at com.sun.jna.Library$Handler.<init>(Library.java:192)
[error] 	at com.sun.jna.Native.loadLibrary(Native.java:646)
[error] 	at com.sun.jna.Native.loadLibrary(Native.java:630)
[error] 	at io.methvin.watchservice.jna.CarbonAPI.<clinit>(CarbonAPI.java:20)
[error] 	at io.methvin.watchservice.jna.CFStringRef.toCFString(CFStringRef.java:23)
[error] 	at io.methvin.watchservice.MacOSXListeningWatchService.register(MacOSXListeningWatchService.java:128)
[error] 	at io.methvin.watchservice.WatchablePath.register(WatchablePath.java:50)
[error] 	at io.methvin.watcher.DirectoryWatcher.register(DirectoryWatcher.java:341)
[error] 	at io.methvin.watcher.DirectoryWatcher.registerAll(DirectoryWatcher.java:315)
[error] 	at io.methvin.watcher.DirectoryWatcher.<init>(DirectoryWatcher.java:176)
[error] 	at io.methvin.watcher.DirectoryWatcher$Builder.build(DirectoryWatcher.java:117)
[error] 	at play.dev.filewatch.DefaultFileWatchService.watch(DefaultFileWatchService.scala:38)
[error] 	at play.dev.filewatch.FileWatchService$$anon$1.watch(FileWatchService.scala:87)
[error] 	at play.runsupport.Reloader.<init>(Reloader.scala:443)
[error] 	at play.runsupport.Reloader$.reloader$lzycompute$1(Reloader.scala:283)
[error] 	at play.runsupport.Reloader$.play$runsupport$Reloader$$reloader$1(Reloader.scala:275)
[error] 	at play.runsupport.Reloader$.startDevMode(Reloader.scala:311)
[error] 	at play.sbt.run.PlayRun$.devModeServer$lzycompute$1(PlayRun.scala:98)
[error] 	at play.sbt.run.PlayRun$.devModeServer$1(PlayRun.scala:81)
[error] 	at play.sbt.run.PlayRun$.$anonfun$playRunTask$3(PlayRun.scala:105)
[error] 	at play.sbt.run.PlayRun$.$anonfun$playRunTask$3$adapted(PlayRun.scala:67)
[error] 	at scala.Function1.$anonfun$compose$1(Function1.scala:49)

Reproducible Test Case

@mkurz
Copy link
Member

mkurz commented Jul 1, 2020

@gmethvin seems like there is a bug in your directory-watcher lib on upcoming MacOS Big Sur.

@gmethvin
Copy link
Member

gmethvin commented Jul 1, 2020

@zhye9452 @mkurz Let's report a bug on https://github.com/gmethvin/directory-watcher/issues and discuss there. In the mean time, I suppose we can switch to an alternative watch service for Play.

@zhye9452
Copy link
Author

zhye9452 commented Jul 1, 2020

@ignasi35
Copy link
Member

ignasi35 commented Jul 6, 2020

I suppose we can switch to an alternative watch service for Play.

While Until there's a fix out of the box, Play users can opt out of the default file watcher using the following play-plugin setting in their sbt build:

// demoes jdk7 but others are available
PlayKeys.fileWatchService := play.dev.filewatch.FileWatchService.jdk7(play.sbt.run.toLoggerProxy(sLog.value))

@17hao
Copy link

17hao commented Jul 15, 2020

I suppose we can switch to an alternative watch service for Play.

While Until there's a fix out of the box, Play users can opt out of the default file watcher using the following play-plugin setting in their sbt build:

// demoes jdk7 but others are available
PlayKeys.fileWatchService := play.dev.filewatch.FileWatchService.jdk7(play.sbt.run.toLoggerProxy(sLog.value))

Maybe we should add dependency: "com.lightbend.play" %% "play-file-watch" % "x.x.x" :)

@mkurz mkurz added this to the Play 2.8.3 milestone Jul 16, 2020
@BassirouRabo
Copy link

I suppose we can switch to an alternative watch service for Play.

While Until there's a fix out of the box, Play users can opt out of the default file watcher using the following play-plugin setting in their sbt build:

// demoes jdk7 but others are available
PlayKeys.fileWatchService := play.dev.filewatch.FileWatchService.jdk7(play.sbt.run.toLoggerProxy(sLog.value))

How can we add it to a lagom project

@ignasi35
Copy link
Member

https://github.com/playframework/play-file-watch/releases/tag/1.1.13 (with BigSur support) is ready.

@octonato octonato modified the milestones: Play 2.8.3, 2.8.4 Oct 26, 2020
@ignasi35 ignasi35 modified the milestones: 2.8.4, 2.8.5, 2.8.6 Nov 4, 2020
@mkurz
Copy link
Member

mkurz commented Dec 4, 2020

I suppose we can switch to an alternative watch service for Play.

I think the long term plan is to completely replace play-file-watch/directory-watcher by sbt's own file watching capabilities, introduced in sbt 1, see #9956

@ennru
Copy link
Contributor

ennru commented Dec 9, 2020

Fixed with #10450

@mariussoutier
Copy link
Contributor

mariussoutier commented Mar 16, 2021

How can we add it to a lagom project

lagomFileWatchService := play.dev.filewatch.FileWatchService.jdk7(play.sbt.run.toLoggerProxy(sLog.value))

@odwrotnie
Copy link

How can we add it to a lagom project

lagomFileWatchService := play.dev.filewatch.FileWatchService.jdk7(play.sbt.run.toLoggerProxy(sLog.value))

It makes no change - I have the exception anyway.

@mariussoutier
Copy link
Contributor

How can we add it to a lagom project

lagomFileWatchService := play.dev.filewatch.FileWatchService.jdk7(play.sbt.run.toLoggerProxy(sLog.value))

It makes no change - I have the exception anyway.

I think then it's not active, there should be no JNA exception now.

Anyway, I don't need it anymore with Azul JDK 11.0.10, native version works fine now on M1 / BigSur.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants