We're having some challenges when attempting to apply the DST
patches to our system. Our plan was to apply the CF 7.0.2 updater
first (we need it now anyway since we're running with some Flex
functionality) and then apply the JVM update as suggested in a
recently posted Adobe.com Technote. We're also running JRUN4.0
version 106363, and serving our pages with Apache
After applying the CF 7.0.2 Updater to our existing CF
installation (CF7.0.1 Enterprise, RedHat Linux AS release 4 (Nahant
Update 2) 2.6.9-22.ELsmp) Java Version 1.4.2_05, when we try to
access any ColdFusion page we get the following error. Has anyone
else experienced similar issues? How did you resolve them? We've
verified that the web server is working as we can call .htm, .css
pages, etc. but none of the .CFM pages work:
Server Product ColdFusion MX
Serial Number CED700-54662-XXXXX-XXXXX
Operating System UNIX
OS Version 2.6.9-22.ELsmp
Java Version 1.4.2_05
Java Vendor Sun Microsystems Inc.
Java Vendor URL
http://java.sun.com/ Java Home /var/opt/jrun4/jre
Java File Encoding ASCII
Java Default Locale en_US
File Separator /
Path Separator :
Line Separator Chr(10)
User Name cfusion
User Home /home/cfusion
User Dir /var/opt/jrun4/bin
Java VM Specification Version 1.0
Java VM Specification Vendor Sun Microsystems Inc.
Java VM Specification Name Java Virtual Machine Specification
Java VM Version 1.4.2_05-b04
Java VM Vendor Sun Microsystems Inc.
Java VM Name Java HotSpot(TM) Server VM
Java Specification Version 1.4
Java Specification Vendor Sun Microsystems Inc.
Java Specification Name Java Platform API Specification
Java Class Version 48.0
Java Class Path info available upon request - it's rather
rich.leach, Mar 12, 2007 6:47 AM
I've attempted this already. The updater has it's own JVM
update build inside of it. Upgrading the JVM according to the DST
docs yeilds the same end-result, null pointer when trying to get to
the CF Administrator.
The 1.4.2_05 is the 7.0.1 JVM. After installing the patch,
it's upgraded to 1.4.2_09-b05.
I'm pretty sure I remember replacing this with the other JVM
(1.4.2_11), and had the same result, but i can try again just to be
after trying this the first time, I mucked things up and
didn't back up the dir. I tried to install the base version, and
the 7.0.1 updater, and have exactly the same problem as the 7.0.2
updater! i had to copy from another web server.
I think it would be prudent to start asking around if anyone
knows of any contingency plans; alternatives to this DST patch
and/or Updater 7.0.2 patch.... unless someone from Adobe can step
up and advise us on what else we could try we'll need to deal with
at least DST on our own, and if the Updater 7.0.2 patch contains
required functionality that we can't simply work without, we may be
forced down a different road, even a different technology.
Is anyone planning to NOT install the DST patch (for whatever
reason(s)), and if so, how are you mitigating the potential
Does anyone know where Adobe has listed all (or as much that
they'll let be known) of the enhancements/changes/updates that the
7.0.2 effects? I'm pretty sure it was required for Flash/Flex
integration, which we were planning on using, but without some
clarity we may be rethinking this part of our initiative.....
Did you get it to work? I just tried to install the DST patch
on one of our 6.1 servers and it did not work. I had
to reinstall a backup of the jvm.config file to get it
working again. What worries me is that I have to update 4
One CFMX 7.02 multiserver, One CFMX 7.02 Server, and two CFMX
No, we're actually putting on all of the latest patches for
the OS as of this posting, then we'll go ahead and try to apply the
CF 7.0.2 patch and the DST patch for the JVM.... will post when we
In my test environment (Fedora Core 6/ CF 7.02) it failed
wondering if we are going to be able to apply this to our
environments (RH ES4/CF 7.02). I know one other state agency
that says they
just aren't going to apply the patch.
"rich.leach" <email@example.com> wrote in
No, we're actually putting on all of the latest patches for
the OS as of
posting, then we'll go ahead and try to apply the CF 7.0.2
patch and the DST
patch for the JVM.... will post when we have results....
.... we finally got the patches to work.... with no thanks to
Adobe, which I'll go into in a minute....
We discovered (the hard way, numerous attempt failures) that
evidently, 2 different 7.0.2 patches exist; one that simply applies
the 7.0.2 code differences to the 7.0.1 existing code base, and a
second code base that is a full version install that applies the
7.0.2 at install time. We couldn't find anything anywhere that
spoke to the differences of getting to 7.0.2 by either either
means; the docs all suggested that you'd have the same end result
if you went with the patches or if you went with the brand new
install. This is not the case, as the 7.0.1 to 7.0.2 patches simply
did not work.
I ended up reaching out to Adobe and opened a Customer
Service Case (number #200175243 in case anyone from Adobe ever
reads this) on 3/7/2007. The automated response I received said
"...You can expect a response within 1 business day. ...." By
3/9/2007 we were getting anxious as we still had not heard back
from Adobe, so I called, got into the que for support, and after 14
minutes on hold was told it would cost $499 for an engineer to
help, since my manager was out of town and we didn't have access to
support contract info. Now, we've got at least half a dozen CF
licenses in house, and with no mention of $499 anywhere in the
Customer Service Case information I felt like we were baited by
Adobe. As of this forum posting, I still have not heard back from
Adobe on this case.
It's rather difficult to be an outspoken evangelist (I even
got certified in CF) for a company's product when they pull the ol'
bait and switch for something they should support in the first
place. At best, post and reveal upfront that your patches aren't
tested, may not work and you'll get charged for support when you
need it from Adobe. And remove the "... response within 1 business
day...." from your communications as it's unprofessional to mislead