[Looking for Charlie's main web site?]

On the cover of the rolling stone...gonna buy 5 copies for my mother

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Well, today I got to experience something I hadn't in 5 years: holding in my hands a book with my name on it. I've not talked about it much, but I'm privileged and honored to be one of the contributors to Ben's 3-part CF8 books (contributing to all 3).

Author copies of the first one arrived today, just as Ray announced also.

The first book is formally called, the Adobe ColdFusion 8 Web Application Construction Kit, Volume 1: Getting Started.

Look for the others (Volume 2: Application Development and Volume 3: Advanced Application Development) to come out in the future. Don't ask me when. I really have no idea.

Still other books in my past

What book did I do 5 years ago that I mention above? The ColdFusion MX Bible, which I did with Adam & David Churvis and Hal Helms. It came out in early 2003, just after the launch of CFMX 6. It got a lot of high praise and good ratings, due mostly to the efforts of "the Churvii" (the father and son Churvis team), who did most of the book.

Here's some trivia: in what other CF book was I a co-author? It's tricky, because if you follow the link for my name on the books above, it shows them only. But search for Charles Arehart instead. You'll see that I contributed to the original CF 4 for Dummies, with John Paul Ashenfelter and Alexis Gutzman. I did just one chapter (on CFMAIL), and as John will tell you, we both decried much of its content but the publisher and lead author were hard-pressed to get it out at the time (2000) and it went as is. The reviews suffered accordingly. I've never blogged my association with that book until now. Hopefully time has cast it to an abyss so there's no harm. :-)

That same year, I also contributed to Professional WAP, doing the chapter there on Wireless programming with CF. (With those multi-author Wrox books, I was listed first so many think I was the lead author, which was not the case.)

Like most, these books are a team effort

And so it was these CF8 books: I'm just one of many hands that make up each of the CF8 books.

But I do want to thank Ben for including me in the books this round. It's a great team of folks spread out over all the books, and I really am grateful for the opportunity to contribute.

Got Digital Voice (or some other cable/phone service) and having problems inside your house?

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Jared Rypka-Hauer today wrote of a hassle he's experiencing with Comcast Digital Voice (their phone over cable service), and he asked if others had thoughts. I may well have an answer for him, or perhaps for others even with other similar phone-over-cable service providers. My wife and I were also suffering with it recently, until a rep found and fixed our problem--a hardware problem. Almost classic, from a geek perspective. :-) Perhaps you too may have it.

Did you previously have another phone over cable service before, like Comcast's "Digital Phone"?

The key question is whether you by any chance had the predecessor to Digital Voice, called Digital Phone (or perhaps any other phone-over-cable service that was like it rather than like Digital Voice, as I'll explain). If so, there may be a problem of something that was left behind in a switch to DV from DP, which could be conflicting with the new DV service. Removing that seems to have solved the problem for us.

Apologies to those who don't like wordy posts, but I want to explain things clearly for the benefit of others in the same boat.

DV service was bad for us--until this was fixed

My wife and I have been Digital Voice customers for about a year, and especially recently we grew VERY frustrated with it for some of the same reasons Jared describes, such as dropped calls, but also failed faxes, problems with the internet service, and even worse, we would occasionally lose all the phone service.

When we lost all phone service, if we connected a single phone to the digital modem (MTA) (inside the house, which feeds the phone line into a jack to serve the whole house), there was indeed signal. So they asserted it "must be something in our house", and they'd tell us to unplug all the phones in the house and wait a half hour, then reconnect. It would always work, but what a hassle! Kind of like a software provider pulling the old "reboot your computer" answer to a tech support question.

Naturally, my wife was fuming and investigating alternatives, when a couple weeks ago we had a rep come out to have a look (what to us was one last look) at things. What he found may well be the clue for Jared or others who had Digital Phone (or anything like it) before Digital Voice. And note that if we simply switched cable service providers, the problem may well have propagated into the new service (since the root cause wasn't the service to the house after all, but it also wasn't a problem inside the house).

What was Digital Phone? And what may be left behind from it?

Comcast's first step into cable-based phone service was Digital Phone. What's the difference? Well, those with the newer Digital Voice (DV) may have noticed that with it, the cable comes into the digital modem (or "MTA") which is inside your house, and out of that comes the phone signal via a normal phone wire that that's fed from the MTA into a normal wall phone jack somewhere nearby inside the house, and that then feeds the rest of the house its signal. There's no more need for any phone line to come into the house, so any outside wire like at the plain old telephone system (POTS) network interface device (or "NID") is disconnected. (picture)

But you may (as we) for a while have used Comcast Digital Phone (which came out before Comcast Digital Voice). And it's important to understand the difference, for this problem. DP worked in a way that was closer to the plain old telephone system (also referred to as POTS). The comcast coax cable from the street went first into a box that was on the OUTSIDE of the house (very much like the one used by the POTS, but a different one: picture). And out of that DP box came both the cable (which went on into the house like it had before installing DP) and also out of it came a phone line, which then was connected to the old phone system box/NID a few feet away, specifically to the phone jacks inside it that then fed phone signal into the house just as it always had in the POTS. (here's a picture)

When they switched us to Digital Voice last year, naturally that phone line into the house (through the POTS NID) was no longer needed, so whoever did the DV install of course removed the phone line going from the DP box into the NID to feed the house, and they set up the MTA inside the house, and so on as needed for the newer DV.

But here's the kicker and what the guy found 2 weeks ago: the DV installer had not only left the old DP box (outside, which he should have removed), but he also left the cable (coax) running through that outside DP box (updated info) and inside of it, it was going through a unit intended to take the DP phone signal out to feed it to the POTS phone box. Then the cable line went out of that box and on into the house. Most important, the rep pointed out that that unit inside the DP box was powered (they had tapped into the power line when they installed that DP box a couple years ago).

Power to the old DP box was interfering with the cable signal

Well, the problem was that the power to that box (and the unit inside through which the cable signal was passing) was directly interfering with the cable signal going out (which of course feeds the TV, phone/DV, and internet service). That would explain a lot of the problems we were having!

So he removed the old DP box (and its power line) updated: opened the old DP box and removed the powered unit inside of it, leaving the box but also disconnecting the power to it. More important he connected the cable inside the unit at that point (what went from the street, and what went into the house) so it was now uninterrupted. The signal is effectively "pure" going into the house, where it then goes to the MTA (the digital modem), and that (as for the last year) feeds the phone line, and the internet service and cable TV that are from there fed into the rest of the house.

So far all has been much better.

Your next steps

If you're not sure if this may be an issue for you (maybe someone had it setup even before you moved into a house in recent years), go out and check if there's a box outside your house on a wall near your phone box that looks like the old phone box. Or find where you cable comes into the house and see if it goes through some other box first, since they may have installed the DP box (or its equivalent) elsewhere outside your house and run a long line to the old phone box. Since that old phone line will likely have been removed, you may not see that.

If you have one of these boxes, and the cable goes into it and then out of it and on into your house, you may well have this problem. Another clue will be if you do (or don't) see a thick power cable feeding into the box. Since it's powered, you won't be able to open the DP box (well, you may find it has a "consumer" side that you can open, just like the old phone system NID, for you to test the phone line outside the house, but that won't show you the cable line to see if it's going through a powered unit as I described.)

But if you have something like this, call Comcast (or your provider, if in a situation like this) to have someone come out and confirm and if so remove it (which should be free, I'd think, especially if they offered the old service to you).

You may then enjoy DV, internet, and tv a whole lot more.

Could be a broader problem

Again, the problem may be generic to other cable systems (RoadRunner, Adephia, Time Warner, Cox, Charter) if they also have offered two generations of phone-over-cable service (or your house may have had it, even if from another provider, before you moved in).

Since setting up things like DV is mostly an "all inside" thing now, some installers may never even think to look at this potential problem. All they may do is unplug the old phone line going into the house and come in and setup the MTA and say, "enjoy". I wonder how many people could be suffering this problem and not know it.

Hope that helps someone.


After writing the entry, I went out to take pictures of the units (which I've added as links above, keeping them rather hi-res to make them more legible). I realized I was mistaken when I said he had removed the old DP box. He had not. But what he did was remove the powered unit inside it and disconnected the power to it (he said) and left the box. I've corrected that above. The problem with this, though, for your diagnosis is that you have no way of knowing--if you do see that second box, the DP one--whether the cable line inside it is still going through the powered unit that should have been removed. You really have no choice, it seems, but to ask Comcast (or your provider) to come out and ocnfirm this, if you are having problems that seem otherwise unresolvable. Sorry for the confusion, but still, I hope it all helps someone.

Speaking at CFUnited Express Chicago, and I'll see you at Max

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
For those going to Max, or who will be in the Chicago area but not going to Max, note that there's the CFUnited Express event going on also in Chicago the day before Max, Sunday Sept 30th. It's a day-long conference (9-5) with several speakers, including myself, Ray Camden, Shlomy Gantz, and others. These Express events are much more intimate than CFUnited (or certainly Max), so it's a great way to meet other CF developers.

I'll be presenting two talks, both of which I've presented before (so well-practiced):

After that, of course, we'll enjoy the rest of the week at Max, and I'll hope to see you there! :-)

CF8 Hidden Gem: New ArgStruct argument for createObject with web services

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Here's another hidden gem in CF8: did you know that there's a new optional "ArgStruct' argument for use with createObject(), when using it to invoke web services?

Following on my previous note about a new RefreshWSDL option in CF8 for CFINVOKE and CFOBJECT, I mentioned there that it was also an option in the createObject() function, but naturally it can't be passed as a tag attribute like with those above.

Instead, it's enabled using this new ArgStruct argument. Technically, it's not "named" ArgStruct but rather it's simply a new optional 3rd argument you can specify when invoking a web service (the term "argStruct" simply comes from the CF docs for the function, where it refers to it by that name. (While yo umay notice that the docs indicate this also allows setting a timeout for the web service invocation, note that that only times out the requesting of the WSDL, not subsequent method calls against the object.)

Anyway, in that structure you create, you simply define RefreshWSDL as a key within it, all of which is passed into the createObject() function as that 3rd argument:

wsargs = structnew();

somevar = createobject("webservice","http://[server]/[webserviceurl]",wsargs);

Of course, you could just as easily do all the above in 3 CFSET tags. It doesn't matter. The key is the addition of the 3rd argument to the createObject(). And it doesn't matter at all what you call the structure (I named mine "wsargs").

Now, you may think this approach seems clumsy, and ask, "why didn't they just permit the refreshWSDL itself as a new argument on the createObject()?". It's a fair question.

But it turns out there's actually a little more to this new ArgStruct option, and it's different enough that I'll talk about it in a separate entry.

CF8 Hidden Gem: Refreshing Web Service WSDL and CF proxy/stub with new RefreshWSDL option

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
One of the many hidden gems in CF8 (and I've found dozens of them) is a new attribute on CFINVOKE or CFOBJECT (and argument for createObject) called RefreshWSDL. It's a another solution to the long-standing problem of invoking web services whose metadata may have changed since previous executions. I'll explain the older approaches, some new in CF 6 and 7, later here for those who missed them.

So what's the problem it solves? If you have CFML code that calls a web service, and one day it just stops working, the problem may be that the web service itself has changed. Perhaps the owner changed the return type or some other metadata.

The new solution allows you to refresh that WSDL on the CFINVOKE or CFOBJECT tags, or the createObject method.


Here's how to do it in CFINVOKE.

<cfinvoke webservice="http://[server]/[webserviceurl]" method="[methodname]" refreshWSDL="yes" ...

Adding it as an attribute for CFOBJECT would work essentially the same way, for those familiar with that tag.

Doing it in createobject()

Doing it in the createObject() function, however, is quite a bit different and leverages some new syntax for that function. I'll show that in another blog entry and will point out another new feature for that function.

There are a couple more points to consider about this, but first I just want to explain why it's needed, for those who haven't heard of such options.

Why should you have to refresh the web service metadata?

Just to back up for a moment, the problem stems from CF's attempt to help. On the first request for a given web service, CF does some caching to make future requests go faster, not caching the results of the web service method but rather the artifacts used by CF based on the description of the web service itself.

CF uses the web service description (WSDL) reported at the time of that first call to create a java proxy/stub based on that, which it then reuses on future calls from CF to that web service.

The issue arises if/when the web service metadata changes. CF won't know, and will continue to use the older cached proxy/stub, and your long-running code may fail if it doesn't match the new WSDL returned by the web service.

So we need a way to tell CF to refresh its cache of that proxy stub.

This new feature is certainly the easiest way to make that happen, but it's not the only way.

Not the only way to refresh the cache, but the easiest

Some may know (and I've written previously) about two programmatic ways to refresh the proxy/stub, whether you're using CF7 (which added a new method in the Admin API) or using CF 6 or above (using an undocumented/unsupported service factory method), as well as an available button in the CF Admin console that could do it (since CF6).

A benefit of this new approach is that it doesn't require you to know the CF Admin password.

Easier, yes, but could be used inappropriately

Of course, with power comes responsibility. You don't want to leave this indicator in your code for all requests, such as in production. That would force CF to do extra work on each web service invocation, defeating the whole purpose of the caching. It's like the tools CFLOG or CFTRACE. Well, more like the former. At least the latter has an Admin console option to disable it even if left in production code.

It's one of those things where opinions will differ. On the one hand, the ease of mistakenly leaving this in to get into into production could make one argue that it ought not be in code, or at least should not be in code calling the web service but rather code to manage the cached stub itself, which is what the previous features did.

On the other hand, those required admin access to perform (except for the unsupported servicefactory approach). Similarly, even if there WAS an option to disable refreshwsdl in production, you'd be stuck if you needed to refresh the cache in production and had no admin access.

At least we have the choices now, and forewarned is forearmed.

Finally, as for more CF 8 hidden gems, I'll note that I've got a user group presentation on the topic, and I have a few dozen more I share. I'll start sharing more of those in blog entries.

Copyright ©2020 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting