Article:
  ColdFusion MX on Mac OS X, Part 3
Subject:   ok... here is a description of my travails
Date:   2002-09-27 14:37:06
From:   dicklacara
Response to: ok... here is a description of my travails

My responses are intermingled.


>>I used an old Linux box running RH 7.x to install CFMX.
>>Here is what I got...


This should be OK


>>1. Did not have enough space on the linux box, tried to
>>change the tmp directory as instructed by the installer
>>program, but the installer failed to install.


Known problem with CFMX Linux installer -- needs 500 Meg to install


>>2. Installed a new hard disk. Installed CFMX successfully,
>> but instead of under /opt/cfmx installed it under
>> /mnt/hdb1/cfmx.


this can be compensated for, see below.


>>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. This is not available on Mac OS X,
and CFMX cannot interface with Apache (or any other web server, except
the Default) without it.


>>3. Tarballed and brought the install tree to my iBook and
>>all hell broke loose because on my iBook I untarred
>>everything under /opt/cfmx.


That should also be OK -- see below


>>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.


#!/bin/sh


# Set some environment variables.
CF_DIR=/opt/coldfusionmx


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.


The only problem with this is you constantly have to interpolate -- all the doce (mine and Macromedia's) are written assuming /opt.


>> Eventually, that
>> got working and I was able to hit and run cf scripts
>> against JRun on port 8500. But, this was
>> soooooooooooooooo slow.


This is not full JRun 4, but one tailored for distro with CFMX.


>>5. Modified the httpd.conf file to load the mod_jrun.so
>> appropriately and run cf the correct way... against the
>> Apache on my iBook. Failed. Seems like the mod_jrun.so
>> that comes with cfmx install is built for Linux
>> only... hence, Apache fails to start.


Again, no Apache without a C++ Connector for the Mac (not available).


>>Bottomline... this is still very tricky unless done pretty
>> much exactly how it is detailed in this article. As is,


Yes this is true... we are bybassing several platform-specific C++ programs, and do not have all the options of a supported platform.


>> hitting against JRun on port 8500 is so slow it is
>> unusable.


That is because you don't have the Default web server.


>>Anyone know if I can get mod_jrun.so for OS X from
>>somewhere? Is this something I can build myself?


Nope, Nope!


>>Tia.


Go back and Linux install with the default web server & redo the port -- it should give you a running CFMX Developer system on OS X, which is the objective of these articles.


Dick

Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • ok... here is a description of my travails
    2002-09-28 21:51:53  punkish [View]

    ..

    >>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.
    >
    >#!/bin/sh
    >
    ># Set some environment variables.
    >CF_DIR=/opt/coldfusionmx
    >
    >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...

    bin/jvm.config

    lib/neo-query.xml
    lib/startk2server

    runtime/bin/jvm.config
    runtime/install_data/getmchn.sh

    runtime/servers/default/SERVER-INF/jrun-resources.xml
    runtime/servers/default/SERVER-INF/jrun-resources.xml
    runtime/servers/default/SERVER-INF/jrun-resources.xml

    wwwroot/WEB-INF/jrun-web.xml

    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.

    pk/
    • 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.

      Dick