Women in Technology

Hear us Roar

  ColdFusion MX on Mac OS X, Part 3
Subject:   ok... here is a description of my travails
Date:   2002-09-28 21:51:53
From:   punkish
Response to: ok... here is a description of my travails


>>Additionally, instead of using the built
>> in server decided to use Apache.
>The CFMX OS X port will not run with anything
>but the default server --
>there is a Platform-speciff C++ file that
>makes the connection between
>JRun and any web server but the default.

yeah, mod_jrun.so... shucks.


>>4. Everytime I tried to start cfmx, it would
>>look for and
>> then create /mnt/hdb1 on my iBook. After
>>much looking
>> around I went it and changed the reference
>>to $CF_DIR
>> in about a thousand places from the hard-coded
>> (by the installer) /mnt/hdb1 to /opt.
>this is the below referenced above
>The 4th line if the coldfusionosx startup
>script sets CF_DIR
>-- you should be OK using the script.
># Set some environment variables.
>If not, you can untar CFMX to whatever
>directory tree that it resided
>on Linux, then change line 4 of the above script.
>I originally installed on /home on Linux and
>ran on /home on OS X.

well, only partially correct. Actually, the install hard-codes the path in
several files. I grep-ed for "/mnt/hdb1" (the path I had installed on
under the Linux box) and found the following relevant files that had to
be modified as well...






additionally, a symbolic link to jvm.config under /bin had to be reset.

In addition, there were a bunch of binary files (classes under
wwwroot/WEB-INF/cfclasses/ that were also matched by grep, but I have left
them alone for now).

Additionally, it seems that the program wants to read in
runtime/lib/license.properties while starting up, however, that file is
sitting under lib/license.properties.

>> hitting against JRun on port 8500 is so slow it is
>> unusable.
>That is because you don't have the Default web server.

still very slow. It seems that the first time I hit any cfm script it
takes forever. While CF compiles and caches the pcode of the cfm scripts
on their first run, the delay in my case seems to be way too much.

Anyway, thanks for a great article... it was very helpful learning all this.


Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • ok... here is a description of my travails
    2002-09-29 07:56:46  dicklacara [View]

    It is true that there are many hard-coded (by the installer) references to the directory path.

    Many of these are XML files that contain initial values that are updated under normal operation of CFMX.

    Others reference the JVM which is is installed as part of the CFMX install. In our startup shell, we bypass this JVM to use the one that is part of Mac OS X -- this makes any changes to files regarding paths to the JVM unnecessary.

    The wwwroot/WEB-INF/cfclasses/ directory is where CFMX stores the templates it has compiled from CFML to Java classes -- these are generated every time a template is changed (or if a Java class for a template is not found) -- so any changes to these should be unnecessary.

    However, it is safest to mirror, on OS X, the directory path used to install on Linux.

    The delay when a CFMX template is hit for the first time (and after any modification) is as you stated to:

    1) Generate Java source code from the CFML
    2) Java Compile the Source code into a Java class file (bytecode)
    3) JIT compile the bytecode into an executable
    4) Cache the executable.

    This only happens the first time a template is hit or after a modification -- so it will have little effect in a production system.

    It is, however an issue with developers who are changing templates all the time.

    There are several ways to work with this, so the delays are tolerable:

    1) modularize your code, using the various features of CFMX, so that changes are localized to fewer and smaller templates. For example CFMX has the concept of a CFC (ColdFusion Component), where a group of related functions can be packaged as a separate module (a CFC) and invoked from other CF templates. So, you could code your business logic or database interface as CFCs. Presumably, these would rarely change. Your presentation logic, which is is more like to change, is smaller (no business or db logic) and compiles faster.

    2) after changing many templates, batch compile these -- the CF-TALK list has included several threads about this.