Yes it is true CFDJ is no more. I was not so much shocked to read about the end of CFDJ HERE, but rather the reasons why.

Engin Sezici's statement about "moving from ColdFusion to other emerging rich web technologies such as AJAX, Flex, and Silverlight" does make one wonder if he actually knows that ColdFusion is a server side technology let alone what it is, because that statement  just doesn't makes any sense otherwise. And anyone who is even remotely familiar with these technoligies knows that they need a server side technology behind them to make them work, and with FLEX being an Adobe product it does of course integrate tightly with ColdFusion and better than it does with other server side technologies.

So aside from the obvious question of how did Engin Sezici get to be an editor on CFDJ, why are they really abandoning ColdFusion.

Well I think that answer is given in the statement "After ColdFusion became part of the Adobe product line Adobe recently decided to discontinue its support of the magazine."

Such a statement might certainly start to make some people wonder about all the other rumours that have been rife about Adobe dropping ColdFusion, although I should point out that I do not believe any of those rumours myself and that there are plenty of facts to the contrary. 

And considering Silverlight is a Microsoft product, I would hazzard a guess that their pockets are now being lined with Micro$oft Dollars instead.

I have to say I wont miss CFDJ, I have always found sys-con to be a useless bunch of muppets. They do not reply to email, return calls, follow up on their promises or make themselves contactable in any way, even if you want to give them your money, they just don't seem to give a doodle-doo about customer service, so I stopped reading CFDJ long ago. And as for their web site, sheesh what a nightmare that is to visit, its just full of annoying advertising, very irritating auto-play videos and bugger all content. 

Following on from all my work with web services in the last 6 months, I have recently had cause to use ColdFusions Query of Queries a lot.

Mainly due to the fact that I am converting web service responses into query recordsets and caching them in memory for later use. Then my web service facades will pull data from these cached queries (using QofQ) instead of calling the real web services.

Now as you should all know, when using components it is best practice to locally scope all your variables so that they are local to each function.

Note that all the below is tested on ColdFusion MX  7,0,0,91690.

E.G.

 But this is where the QofQ problems begin. It seems you cannot use more than one scoped query name. You also cannot use the word "LOCAL" as it is a reserved word, and will cause your query to fail with a less than helpful error. So when using QofQ within a CFC, you need to use the variables scope to store the queries so taht you do not need to use the scope in the actual query.

Here are some examples

I also noticed this rather odd behaviour as well.

When joining 2 queries as above, lets say you wanted to select all rows that do not meet certain conditions, as I did. Well using <> or != does not work. You have to use the NOT clause instead.

E.G. 

 What happens in the first 2 examples is that rows are returned if eaither side of the condition is true rather than BOTH.

I have been a lot of work with SOAP recently, consuming 3rd party web services written in JAVA and .NET. And I have come to the conclusion that ColdFusion really does suck when it comes to this particular area.

why do I say this, well basically I feel that Adobe have tried to be too clever with the web services and rather than make it easier for CF to work with SOAP they have in fact made it more of a PITA.

1. When you try to consume a web service, the first thing that CF does it download the WSDL and create JAVA stubs for all the methods. This can be the start of your nightmares. Any errors in the WSDL, or anything that JAVA doesn't like, and the stub files will not be created and you will not be able to consume that web service. You also will not get back any kind of remotely useful error message either. So unless the 3rd party is prepared to modify their web service (unlikely) then your screwed. Also the initial request will be very slow while the stubs are generated, and any changes to the WSDL will not be picked up unless you delete the web service definition from the CFADMIN.
   
   Here is an example of the type of error you might get when the stubs cannot be created.
   
   

   coldfusion.jsp.CompilationFailedException: Errors reported by Java compiler: Found 3 semantic errors compiling "/opt/jrun4/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/stubs/WS888823651/fi/atex/www/namespace/Atex/Web/Advertising/Logo/LogoServiceLocator.java": 53. return _stub; <---> *** Error: The type of this return expression, "fi/atex/www/namespace/Atex/Web/Advertising/Logo/LogoSoapBindingStub", does not match the return type of the method, "fi/atex/www/namespace/Atex/Web/Advertising/Logo/Logo". 74. return _stub; <---> *** Error: The type of this return expression, "fi/atex/www/namespace/Atex/Web/Advertising/Logo/LogoSoapBindingStub", does not match the return type of the method, "java/rmi/Remote". 94. return getLogo(); <-------> *** Error: The type of this return expression, "fi/atex/www/namespace/Atex/Web/Advertising/Logo/Logo", does not match the return type of the method, "java/rmi/Remote". Found 1 semantic error co....

   
   
   
2. Creating a SOAP request in CF can also be a total nightmare as you do it with arrays and structures and CF then tries to convert it into SOAP when you invoke the service. Simple variables are no problem, but when you need to create a request comprising of complex nested variable types, the fun and games begins, as CF just wont produce the required SOAP request in the required format.
   
   E.G. Here is part of a required SOAP request, generating this in CF as nested structures does not produce the desired result due to the fact it is a nested set of complex variables.

   <insertions>

       <item xsi:type="ns2:insertion">

   
           <adContent xsi:type="ns2:adContent">

               <color xsi:type="ns2:color" xsi:nil="true"/>

               <id xsi:type="xsd:int">0</id>

               <messages xsi:type="soapenc:Array" xsi:nil="true" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"/>

               <overmatter xsi:type="xsd:boolean">false</overmatter>

               <proofURL xsi:type="xsd:string" xsi:nil="true"/>

               <size xsi:type="ns2:size">

                   <depth xsi:type="xsd:double">30.0</depth><depthUnit xsi:type="xsd:string">mm</depthUnit>

                   <width xsi:type="xsd:double">31.0</width><widthUnit xsi:type="xsd:string">mm</widthUnit>

               </size>

               <styleId xsi:type="xsd:int">509</styleId>

               <text xsi:type="xsd:string">uploadFile26863.tmp</text>

           </adContent>
        </item>
        <item xsi:type="ns2:insertion">

   
           <adContent xsi:type="ns2:adContent">

               <color xsi:type="ns2:color" xsi:nil="true"/>

               <id xsi:type="xsd:int">1</id>

               <messages xsi:type="soapenc:Array" xsi:nil="true" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"/>

               <overmatter xsi:type="xsd:boolean">false</overmatter>

               <proofURL xsi:type="xsd:string" xsi:nil="true"/>

               <size xsi:type="ns2:size">

                   <depth xsi:type="xsd:double">30.0</depth><depthUnit xsi:type="xsd:string">mm</depthUnit>

                   <width xsi:type="xsd:double">31.0</width><widthUnit xsi:type="xsd:string">mm</widthUnit>

               </size>

               <styleId xsi:type="xsd:int">509</styleId>

               <text xsi:type="xsd:string">uploadFile26863.tmp</text>

           </adContent>
        </item>

   
   </insertions>

   
   
3. When providing your own web service for others to consume, the SOAP response created by CF is not very developer friendly at all. CF tends to generate xml attributes instead of tag entities.
   

 In all the above situations you are better of manually creating your own SOAP request/response and sending this off the old fashioned way via a cfhttp post, which is in fact also quicker as you are bypassing the java stub files.

Below is an example of manually consuming a web service with your own hand crafted SOAP request. To generate and test your SOAP requests I recommend a handy tool called SOAP UI which will read your WSDL and create a default request for each method saving you a lot of time. All you need to do is fill in the data and submit the request, wheny ou have it working, just paste the request into your CF code and off you go.

If you get this Axis error like the one below when trying to consume a CFC web service, or even when trying to browse the WSDL with your browser, here are a couple of possible reasons why.

1. You have a default "/" mapping in your cfadmin, this breaks CFC's in general.
2. You have a mapping with the same name as one the folders in the path to your CFC
   

Remove said mapping and u should be fine.

I have been having an issue on one of our servers with CFX (java) tag not working.  Basically after installing the tag and adding it via the CFADMIN any use of the tag would just result in a blank page, no errors nothing, the tag simply did not work.

The coldfusion-event.log would contain the following error.

It turns out that it is required to have the path to the CFX.JAR file in the JVM Classpath in your jvm.config file, at least in my situation. I am not exactly sure why this is required on this particular server, as I have checked on several other servers and they do not have this path. Only one other server had this path and it was listed under the shared libraries path and not the jvm class path.

Give it a try, it may work for you also if you are having this problem.

open your jvm.config file, and add the following to the end of the JVM CLASS PATH

{application.home}/../wwwroot/WEB-INF/lib

NOTE: This applies to the standalone install only. If you are running CFMx on top of JRUN or any other J2EE server you will need to modify the paths accoridngly. Just find your CFX.JAR file and create the path to that folder.

I also want to mention that the CFMX documentation on adding CFX tags is lousy. If you search online you will mind many different suggestions on how to install a JAVA CFX tag, some will tell you to add the FULL path to the JAR file and put it in the lib folder  (e.g. {application.home}/lib/cfxtag/jar), some will tell you to use a windows filesystem path (e.g. c:\cfusionmx7\cfx\mytag.jar) and a myriad of others.

The method I have always used is to simply put your CFX tags into c:\cfusionmx7\cfx and add "{application.home}/../cfx" to the jvm class path As long a sthere are no other problems, such as the one above, then this should work.

Thanks to Mark Drew for helping me solve this.