Cannot run on MacOS without a bundle

[LorenzoDV]

Hello.

I'm facing a big problem with JCEF on MacOS 10.12 when I try to run it from Java directly, without using the bundle generated by appbundler.

First of all, I know that CEF has some hard-coded paths that make it difficult to run without the correct directory structure.
Thanks to the comments in http://bitbucket.org/chromiumembedded/j ... -icudtldat I am already using the --framework-dir-path and other command line flags as a first step towards unbundling. I plan to eventually switch to CefSettings to set the same paths programmatically.

The problem now is that I cannot move the executable outside of the bundle. I would like to demostrate that it can run with the installed java executable, but when I try to do that Chromium fails to start and renders a blank rectangle.

Here is the log for the failing run. The only logged errors are two bootstrap_look_up: Unknown service name (1102).

Code: Select all

Offscreen rendering disabled
Using:
JCEF Version = 3.3538.206
CEF Version = 3.3538.1852
Chromium Version = 70.0.3538.102
AppHandler.stateHasChanged: INITIALIZING
initialize on Thread[AWT-EventQueue-0,6,main] with library path /Users/jenkins/Desktop/JCEF/Eclipse/workspace/MyJCEF/lib/native-libs/jcef_app.app/Contents/Java/
Added scheme search://
Added scheme client://
AppHandler.stateHasChanged: INITIALIZED
[1208/224416.677782:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Unknown service name (1102)
BrowserFrame.onAfterCreated id=1
[1208/224419.721068:ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Unknown service name (1102)
BrowserFrame.windowClosing CefBrowser.close(false)
BrowserFrame.doClose id=1 CefBrowser.doClose=true
BrowserFrame.windowClosing CefBrowser.close(true)
BrowserFrame.windowClosing Frame.dispose
BrowserFrame.onBeforeClose id=1
BrowserFrame.onBeforeClose CefApp.dispose
AppHandler.stateHasChanged: SHUTTING_DOWN
shutdown on Thread[AWT-EventQueue-0,6,main]
AppHandler.stateHasChanged: TERMINATED


It only works if I use the executable in the Context/MacOS directory (JavaAppLauncher). The best I could achieve was putting a symlink to the java executable in Contents/MacOS, named exactly JavaAppLauncher. Any symlink not named like the executable mentioned in the Info.plist file of the bundle causes the above problem.

After days of research I suspect that the problem is the establishing of the IPC channel between CEF and Chromium which is somehow related to the bundle or to some kind of app sandboxing that kicks in when the executable is detected as "unbundled".

The strange thinig is that I cannot find any mention of the problem, while I see numerous reports of people running JCEF using the global java on their path. For example, the last post of http://bitbucket.org/chromiumembedded/j ... -icudtldat just 4 months old, they report a successful run via exteernal java.

I'm really stuck on this problem Any help would be very much appreciated.
Please tell me if you need more specific information.

Thanks in advance.

--
Lorenzo

[Czarek]

Have you enabled CEF logs? See CefSettings.log_severity and log_file.

[LorenzoDV]

I had only Chromium logs enabled. Now I have also enabled CEF logs as you suggested.
I am using these options.

Code: Select all

--log-file=<path> --log-severity=verbose --enable-logging --v=9

I'm sharing the two logs in this Google Drive folder: https://drive.google.com/drive/folders/ ... sp=sharing (for some reason phpBB is rejecting the upload here).

• failing.log - The executable is a symlink to java placed in Contents/MacOS but NOT named JavaAppLauncher
• working.log - The executable is a symlink to java placed in Contents/MacOS and named JavaAppLauncher

The symlink name is the only difference between the two cases.

Do you see anything useful in the logs?
Thanks.

[Czarek]

CEF only supports the official bundle/structure, so if you want to do things differently you're pretty much on your own.

You could try calling CefOverridePath, see the patch:
https://github.com/chromiumembedded/cef/pull/4

[LorenzoDV]

You could try calling CefOverridePath, see the patch:
https://github.com/chromiumembedded/cef/pull/4

I was hoping to avoid that route, but I might give it a try since I'm really out of options.

Using that patch requires me to build CEF in addition to JCEF, right? Can the prebuilt "upstream" binaries of cefpython be of some help? I mean, do they include the patch? https://github.com/cztomczak/cefpython/tags

[Czarek]

Yes, yes and yes.

[magreenblatt]

• failing.log - The executable is a symlink to java placed in Contents/MacOS but NOT named JavaAppLauncher
• working.log - The executable is a symlink to java placed in Contents/MacOS and named JavaAppLauncher

The symlink name is the only difference between the two cases.

If you’re running by clicking the app bundle in Finder then you probably need to change the CFBundleExecutable value in your Info.plist file. If you’re not setting CefSettings.browser_subprocess_path then the helper app bundle name and executable also need to match.

[LorenzoDV]

you probably need to change the CFBundleExecutable value in your Info.plist file. If you’re not setting CefSettings.browser_subprocess_path then the helper app bundle name and executable also need to match.

Thanks for the tips magreenblatt. Unfortunately my goal is to have no application bundle at all: those experiments only demostrate that the bundle is required, for some reason, but I would like it not to be required.

[Slartie]

You should take a look at my CEF fork on GitHub: https://github.com/S1artie/cef/tree/3578

I've had the same problem and wanted the same thing (not being bound to that app structure, actually my goal was to dynamically extract all CEF/JCEF binaries and resources from JARs at runtime, for all three OSes, which I can now do with CEF/JCEF 3.3578, but only with patched versions of both).

With 3.3497, the Mach IPC connections were somehow not a problem yet, which explains why this worked for you as well before. But when I upgraded to 3578, I had to do this little patch here: https://github.com/S1artie/cef/commit/8 ... 8dc2f1f4R9

Effectively it erases the dynamic parent bundle ID detection and replaces it with a static string. I don't see any downsides at all with this - after all, the purpose of this stuff is to prevent registered name collisions, and even if there are multiple CEF-using applications, they differ in process ID, which is also part of the registered name.

The same commit also extends the dynamic linking of libcef to allow me to pass my own location of the framework into JCEF on the call to startup(). It only works in conjunction with a JCEF patch on my custom JCEF fork: https://github.com/S1artie/java-cef (on this one I patched quite some stuff that came in handy for my specific purposes, but that doesn't have anything to do with running outside of app bundles, so you might want to just cherrypick out specific commits from there).

[LorenzoDV]

You should take a look at my CEF fork on GitHub: https://github.com/S1artie/cef/tree/3578

Thanks, Slartie! Apparently, we were struggling with the exact same problems last week

I started using (J)CEF only recently, so I didn't know for how long the Mach port problem has been present. The fact that it is recent explains why there are so few people affected.

I agree with your reasoning about the Mach port name: why use the bundle id when you have the PID? It is just looking for trouble if you ask me! I can only imagine that working with bundles is so natural on OSX that the developers did not consider the case of running without them.

I was also planning to patch JCEF like you did, to expose framework configuration. Your commits will sure come in handy!
The big problem for me is now the build time. It takes FOREVER to build CEF on my crippled MacMini.