CFMXLauncher Simplifies ColdFusion On Mac

Caklrification: I believe that's for Mac on Intel hardware (not yet a supported configuration for ColdFusion Server). CF 7.0.1 is fully supoprted on Mac OSX on PowerPC hardware and doesn't need this utility to launch, just to be make sure folks are clear :) Damon

I just want to be clear about this, so I'll say it again here: This isn't just for Intel Macs... this is for any Mac that returns the following when you type java -version at a command prompt: java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) I have a better understanding of WHY the CFMX launchers that come with CFMX break on OSX when you have the JVM 1.5 update installed, but, and this is important: It allows you to let your system keep the 1.5 JVM as the system-wide default JVM AND very easily run CFMX as a daemon (detached from any terminal window or dock icon). I just want to make sure that people understand what's really going on here... Thanks!

Damon, When Apple released their Java 5 update for OSX 10.4, many people got a very nasty surprise... the CFMX launchers included with the OSX version are hardcoded to use the default OSX JVM regardless of any config file settings. This is borne out not only by my experience, but also by Steven Erat's blog posting titled "Making ColdFusion MX on Mac OS X use JVM 1.4.2 instead of JVM 1.5.0" which includes instructions not on how to get CFMX up and running with JVM 1.4.2 but how to change the default JVM for OSX. As many of us discovered, to our great frustration, this seemed to be the only way. Enter the MacBook Pro, running OSX 10.4.7... default JVM? 1.5... only 1.5 has a number of improvements that affect other software and I don't want to run JVM 1.4.2 for everything on my box... which left me with a conundrum: Run JVM 1.5 and don't run CFMX on my box or run everything under JVM 1.4.2. Yuck. Only I did discover that you can use the path to the JVM 1.4.2 executable to launch jrun.jar, which is how the StartCFMX widget works. This means that anyone running OSX and actually wanting to run JVM 1.5 on their computer actually can, and still run CFMX at the same time. What I'd like to know is why the shell scripts (like /Applications/Jrun4/bin/jrun) and the actual CFMX launcher that comes with the OSX version (/Applications/Jrun4/ColdFusionLauncher.app) all use the hardcoded path to the freakin symlink /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK instead of a configurable Info.plist entry in /Applications/Jrun4/ColdFusionLauncher.app/Contents/Info.plist config file. And since the .app mechanism under OSX allows for the use of either a shell script or a binary for .app packages, why not use a shell script? Basically, if you want to use JVM 1.5 as your default system JDK and still run CFMX on your Mac you *don't* have a choice but to use a launcher of some sort like this one, and this is the only one I've found... and I didn't find it, I wrote it. :D Laterz, J

MAX, Mac ... :-) Thanks for catching that one. --- Ben

Does Ben have Adobe MAX in Vegas on the brain, or was I asleep when "Max" because the plural of "Mac?" Al

Dean, While I've messed around developing a little bit under OSX I'm nothing even close to proficient at some things and there are others that I don't understand in the least... what I do know is this... Using: <key>JVMVersion> <string>1.4*</string> in the launcher's info.plist allows you to specify the highest version available of 1.4, rather than the highest available version past 1.4, which is the default in the info.plist file (indicated by 1.4+ instead of 1.4*)... I'm not sure exactly what the mechanism is that the launcher uses to run CFMX, but could this difference help get this working? Thanks, J

It's because that's not what we do to instantiate the VM. After all the arguments and stuff is parsed, we call the C functions to get the VM and load it into memory, we do not just shell out with an execprocess (or whatever the Mac equivalent is). This is what is called to get the method used to actually create the VM: NSLookupAndBindSymbol("_JNI_CreateJavaVM"); As you can see, there's nothing in there to specify what vm to load. The dylib is loaded by the linker, and we ask for the function to load create th VM. Since the dylib with the function in it is loaded by the system (in this case it's libjvm.dylib), and not by us, we have no control and Apple refuses to give it to us. It can't be statically linked, and loading it dynamically doesn't give you the option of where to load it from. Kinda sucks, really.

I think I learn more from being noisy and then corrected than I do from any other process... ;) Dean, thanks for the feedback... I am coming to understand the situation better. It is, apparently, a massively sucky situation, fair enough? Sorry for any perceived slam. It was the frustration talking. OK, so here's the question: If I can get CFMX to launch using the 1.4.2 JVM by specifying the full path to the JVM I want (/System/Frameworks/yadda/yadda/1.4.2/bin/java) and CF runs (beautifully, too, I might add... blistering fast) why can't the C code used to launch it do something similar? My one line of code kicks CF off and, while it admittedly runs with the JVM defaults for the -server switch, works great for running a copy of it locally for my development needs... I've gotten emails from a half-dozen people who have used it and they're ecstatic to be able to use CFMX on their MacBooks or, iike myself, simply happy to be able to run the 1.5 JVM for everything but CF. I KNOW that Apple has built OSX around a huge, complex array of frameworks and their doco isn't always the best... it just seems impossible that y'all Smart People from Macrodobia can't get this thing off the ground by some means. Again, sorry for any perceived slight against you and thanks for the correction. I'm slowly starting to "get it" and getting it is the first step toward understanding that if a quick-and-dirty fix was available you'd have implemented it already... that doesn't really fix my problem, but it does make it a little easier to accept. Laterz!

Jared, what you are suggesting is not quite right and is not "what is really going on". We do not use the symlinks. Under the hood, the jrun launcher binary (what you will find in /Application/ColdFusion MX 7/runtime/bin) does a lot of work. It is this that launches the vm, sets up a bunch of stuff in the vm, and then launches the the proper jar file. All that fun (and important) stuff that you set up in jvm.config, well, that's what we use. It does not simply do a "java -jar cfusion.jar". Lots, *lots* more goes on in the way the vm is constructed, paths are set, etc. It's the underlying calls we make from the C code in the launcher that do not allow us to specify the vm, not because of anything we have control of, but because that's the way Apple made it. When we tell it to instantiate the virtual machine, no matter what we do it uses the one registered with the system because that's what the system wide libraries do. We also could not make a VM of our own and ship that so that people would not have problems, Apple prevented it specifically with licensing terms (among other things). When we called their tech support to get help, they were apalled that we would even want to do such a thing. "Why would you not do what we told you to do?" was essentially the answer. I kid you not. And you thought Microsoft was bad? At least I get answers from their tech support and on the MSDN. If you don't do what Apple wants, well then they pretty much tell you to screw off. On a Macintosh, Apple controls the VM and tells everyone else to go jump in a lake (unlike *every* other OS out there, when the application can choose what to do, silly Macs). When I told the C code to launch with the 1.4.2 VM, and the 1.5 one was the system default, the 1.5 one launched. Very frustrating, let me tell you. As to the 1.5 vm, well, 7.x does *not* officially support this configuration. We tried to make it play nicely, true, but it is not officially supported. Do this at your own risk. And if stuff breaks (like, say webservices and verity), the first thing tech support will do is tell you to switch back to the 1.4.2 VM.

Does Ben have Adobe MAX in Vegas on the brain, or was I asleep when "Max" because the plural of "Mac?"

good post!

good post!

While this sort of information is appreciated, what would be even MORE appreciated is a statement from Adobe/Macromedia as to when they're going to get around to actually fixing the problem themselves. Or even if they're planning to do so, so I and my customers can get on with selecting a different platform. I thought one of the reasons for rebuilding the thing in Java was platform independence and to make it easier to port to new systems? Or if a multinational like Adobe can't hack it, then cut the thing loose and make it open source. Heck, MySQL had their entire database system available for OSX Intel ONE WEEK after the release of the first systems to consumers. Now THAT'S service.