cfdump errors out

BKBK - thanks for the tip. We had some problems with administrative screens on our dev server that were solved by that hotfix. That could well be the root of this problem - Dave

And here we have it - thank you Adam!

Interestingly, there was no cfdump file in the \cfclasses folder. For some reason the file wasn't being generated(!) I copied the dump file from the updater 3 install over the existing dump file in the \cftags folder and, as they say in France, "Votre oncle, c'est Bob".

Many thanks again for your help! Now I can concentrate on workarounds for things like the site-wide error handler showing content from the page that errors, and not being able to define more than one custom error type, because CF always picks the last cferror handling a custom error type, no matter which custom error you throw. You know, the easy stuff.

Eternally grateful,
Dave

> Also Also, do you think it would work to find the cfdump file in the /cfclasses
> folder you mentioned and delete it and reboot, instead of deleting them all and
> rebooting? i.e. "cfdump2ecfm659484891.class"

Yeah, go on. That should be sufficient.

--
Adam

> need. We stabilized after updater 3 (on some workarounds) and stood pat.
> We're a very small shop sitting on a large code library, and we're a little too
> gunshy, I think.

I know that feeling.

> That's not an excuse, just an explanation. Your endorsement
> of 6.1 is heartening. What version are you using now, and do you have any
> cautionary tales to tell about the upgrade process (aside from the CFCs)?

From memory there was an updater to 6.1 that had a build number of 6xxxx,
which was a bit twitchy, but the last one which was numbered 8xxxx (I
think... this is a hazy memory) was pretty solid. The worst thing with 6.0
and 6.1 was that each updater version required a different [minor] version
of Apache, and that was a pain in the butt to keep up with.

It took me a while to jump to CFMX7, as there was nothing really in it I
needed, however the jump was smooth once I did so (probably only about 6-9
months ago). Macromedia "broke" the duplicate() function in that it now
throws an exception if you try to duplicate() an object, instead of just
turning it into a struct as it did in previous versions. That revealled
some shoddy code of ours, once the exceptions started to show up, but that
was the only re-work we had to do, from memory.

7.0.1 was the work of satan (well, OK, it broke a couple of things we rely
on not being broken), but 7.0.2 has fixed those. I never used 7.0.1 in
production.

The latest version of our software requires 7.0.2 to work (not sure why...
I'm not on the dev team any more), so I have upgraded to that, quick smart.
It seems fine

CFMX7 has got some nice-ish - if not essential - stuff: async gateway,
admin API (which I have not used), Application.cfc (again, haven't used
yet, but it's higher on my list to look at). It's also got some half-arsed
b*llshit which I would never have use for: <cfreport>, <cfdocument>, Flash
forms and the like. These features SOUND good, but they're implemented a
bit half-arsedly, so don't quite make the jump from being "an OK proof of
concept" to "something actually useful". I'm sure mileage varies on that
opinion, so don't take my word for it.

Good luck with your <cfdump> problem. Let us know how you get on.

--
Adam

Also Also, do you think it would work to find the cfdump file in the /cfclasses folder you mentioned and delete it and reboot, instead of deleting them all and rebooting? i.e. "cfdump2ecfm659484891.class"

Also, re: accessing scopes as structures, that's what I was afraid my only solution would be. Afraid, I say, because I think that would require a recursive function to deal with arrays within structures within structures, etc., etc. In my foetid laziness, I was hoping someone else had taken the trouble to do that, but then again, I guess someone has, and they called it <cfdump>. And to throw it in an error template - well, let's just say cferror and error handling in general has proven to be selectively effective, or at least not as advertised. 7.0 is looking better and better. Please tell me error handling gets better.

Right, Adam - taken in the spirit it was intended! After going through the first three updaters, and having problems still plague us after each one, we came to the conclusion that it wasn't worth upgrading unless we had a clear need. We stabilized after updater 3 (on some workarounds) and stood pat. We're a very small shop sitting on a large code library, and we're a little too gunshy, I think. That's not an excuse, just an explanation. Your endorsement of 6.1 is heartening. What version are you using now, and do you have any cautionary tales to tell about the upgrade process (aside from the CFCs)? Thanks for the ideas - I'll see what we can try and let you know what works.

It would be easy enough to write a UDF that would dump out the contents of
a struct:

function dump(o){
var sKey = "";
for (sKey in arguments.o){
// if it's a simple value, just output
// if it's a struct, call dump(o[sKey]);
}
}

Obviously you're gonna want to dolly it up a bit. And also consider what
you want to do with other complex objects, such as queries and arrays, etc.

One thing to consider is that <cfdump> is itself just a custom tag, and
should be portable between CF servers (maybe even versions). On my install
it is here: [instance dir]\cfusion-ear\cfusion-war\WEB-INF\cftags\dump.

Maybe your production box has become corrupted, so replace the prod one
with the one on dev.

Another thing to try would be to stop CF, delete anything in [instance
dir]\cfusion-ear\cfusion-war\WEB-INF\cfclasses, and restart. This will
force all the templates to recompile, next time they're called. You will
experience a major slow down during this process (a shortcoming of CFMX60),
but that'll come right once all your templates have recompiled. I have
found those class files to get corrupted sometimes. Esp on... CFMX60.


I hope you are not using CFCs in CFMX6. You will have to recode a lot of
them when you upgrade. CFMX6's implementation of CFCs is poor, and across
the board it is very slow due to how it compiles the CFML to Java.

However I understand doing an upgrade is not something to undertake
lightly. That said, you should never have KEPT running CFMX6 once CFMX61
came out. Can't be helped now, though, I guess.

My take on 6.0 is that it amounts to a beta of 6.1 (note: not even a
release candidate, a BETA).

PS: I'm not having a go @ you, just wording it strongly to try to get
across the point that it's not just a cosmetic upgrade, it's an essential
one.

--
Adam

Thanks for your replies, Ian and Adam.

Honestly, Ian, I agree. I usually use that syntax as well. Saw it without the quotes in some documentation and gave it a try that way -that's what I posted.

As for going to 6.1, we've been using 6.0 updater 3 for many moons, and I'm sure we'll upgrade to 7.0, or the next incarnation sometime this year.

In the meantime maybe this will (at the risk of referencing Jerry McGuire) help you help me: Aside from the obvious benefits of using cfdump as a debugging tool, I had hoped to use it in the email I send to myself whenever an error of type "exception" occurs to spit out the contents of the variables in all the usual variable scopes. Is there some snippet of code that would allow me to easily display, for instance, the entirity of the #error# or #session# scopes without using cfdump (including sub-structures)?

or B.... If this installation is faulty, is there something I could do short of reinstalling to fix this particular problem? It seems unlikely, assuming I'm the only human being on the planet for whom cfdump doesn't work (and I've looked ), that there's not something wrong with a file somewhere. Which file would that be and how do I replace it?