Tuesday, September 25, 2007

ColdFusion 8 Getting Started code available

In the past, we have shipped the entire "Getting Started" application and code in the installer with the server. This bloated the download size (and its already big). So for ColdFusion 8 we had Adobe IT put Getting Started on a cluster of servers available on the net. You can check it out here. This makes our download smaller and ensures customers access to correctly configured servers.

But for those of you who want to look through the example code and/or run on your local machine not connected to the internet, we have made the entire set of files available on Adobe.com. Just go to the ColdFusion Developer Center and click on the "Downloads" tab on that page.

Or if you want a direct download link, you can use this.

7 comments:

Anonymous said...

Just a heads-up:

system functions > setLocale doesn't display anything.

Zac Spitzer said...

it would be nice if adobe started providing such things via subversion, for updates and the like

SLOAN.BL said...

Hi Tom, can you tell me if Axis2 is available in ColdFusion 8? I've been scanning the web and can't find an answer. Thank you!

Tom said...

@sloan - No, ColdFusion 8 has not changed its web service engine from Axis to Axis2. We are looking at this for the next major release, but this might seriously break compatibility so we have to tread carefully.

Anonymous said...

Has there been in movement in the area of moving from Axis to Axis2? I noticed this last post was from May 2008.

Tom said...

@anonymous - Centaur, the next major revision of ColdFusion, is just going in to Beta and is expected to be released later this year. Since Axis2 is not backwards compatible with Axis, and since it does not support the rpc/encoded style of web services as well as Axis did, it seems unlikely that we will do a full replacement in the near term. We are considering all of the options however.

Alan said...

If anyone is interested, I have been able to make ColdFusion 8 work with Apache CXF, which supports a variety of web service standards and libraries - SOAP 1.1, SOAP 1.2, REST, etc.

Caveats: CF8 works with CXF in the sense that CXF objects can be instantiated as Java objects in CFML and their operations successfully invoked. It does NOT work as a native CF web service call using <cfinvoke webservice="..."> or CreateObject("webservice", "..."). Also, this technique requires some low-level changes to the default CF8 installation, so it is not for the faint of heart.

In general, the procedure is to grab the CXF libraries and get CF to recognize them. You can drop them directly into a /lib folder that's in the CF classpath, or if you want to be a bit more cautious you can point the CF classpath to the folder that contains the CXF JAR files.

Detailed steps:
1. Download the latest CXF distribution and extract/install it somewhere. If your CXF root is /foo, then find /foo/lib. You'll see a bunch of JAR files, and your mission is to get CF to recognize these files and load the classes in them.
2. Stop the CF server.
3. CF8 and the JRE that comes with it use an older, incompatible version of the JAXB library, so we need to get the newer one in place. Create /foo/lib/endorsed and copy the jaxb-api-version.jar file into that folder.
4. Find jvm.config in your CF installation and open it in a text editor. Append the following to the JVM arguments: -Djava.endorsed.dirs=path_to_foo/lib/endorsed -Djava.protocol.handler.pkgs=javax.net.ssl. Find the string -Dcoldfusion.classPath= in the JVM arguments and place the path to /foo/lib immediately after the equals sign (i.e., at the FRONT of the classpath), with a comma to separate it from the rest of the classpath entries. Do not set the classpath using the CF administrator. It will not permit adding elements to the front of the classpath, and will in fact overwrite the classpath if it is used to change Java settings at any future point.
5. A suspected bug in the CF classloader causes the wrong part of the CF architecture to load the SAAJ classes. Get around this by copying /foo/lib/saaj-api-version.jar into {java.home}/lib of your CF installation. Then delete or rename saaj-api-version.jar in /foo/lib so it does not get loaded from that location. Also delete or rename saaj.jar from the main CF library location (ColdFusion8\lib on a Windows installation, standalone configuration).
6. Disable the native JAXB library in ColdFusion by deleting or renaming jaxb-impl.jar in the main CF library location.
7. Restart the CF server.

With these steps, you will be able to invoke Java objects that serve as clients for the web service endpoints. These Java objects need to be created, compiled, and installed to a location in the CF classpath in order to be invoked. The CXF documentation describes ways to create the Java objects; wsdl2java might be your best bet. You can have it create classes that are SOAP 1.1 and SOAP 1.2 compatible, allowing you to call those services via the Java objects from inside ColdFusion files.

After doing this, I did a cursory test of the native CF web service functionality (Axis 1.1) and it seems to work still, so existing code shouldn't be affected.

I'm posting this here since this was the best place I could find in my research that discussed post-Axis 1.1 support in CF. Hope you don't mind, Tom.